CEN-CENELEC-ETSI Smart Grid Coordination Group

November 2012

CEN-CENELEC-ETSI Smart Grid Coordination Group

Smart Grid Reference Architecture
Contents Page

Main changes in this version ......................................................................................................... 4

Foreword ....................................................................................................................................... 5
1 Scope ...................................................................................................................................... 6
1.1 How to use the document .................................................................................................... 6
1.2 Approach to the problem domain......................................................................................... 6
1.3 Outcome: an architecture framework and a mapping methodology ..................................... 7
1.4 Main target audience: Standardization Technical Committees ............................................ 8
1.5 What is not in the scope of this document ........................................................................... 8
2 References ............................................................................................................................. 9
3 Terms and definitions.......................................................................................................... 11
4 Symbols and abbreviations ................................................................................................ 12
5 Executive Summary ............................................................................................................. 14
6 Conceptual Model and Reference Architecture Principles ............................................... 17
6.1 Motivation for Conceptual Model and Reference Architecture ........................................... 17
6.2 Requirements for the M/490 Reference Architecture ......................................................... 17
6.3 Conceptual Model ............................................................................................................. 18
6.3.1 Introduction ................................................................................................................... 18
6.3.2 Approach and Requirements ........................................................................................ 19
6.3.3 An EU extension of the NIST Model.............................................................................. 20
6.3.4 The Flexibility Concept.................................................................................................. 22
6.3.5 Conclusion .................................................................................................................... 22
6.4 Reference Architecture Viewpoints .................................................................................... 22
7 The Smart Grid Architecture Model (SGAM) Framework .................................................. 24
7.1 Interoperability in the context of the Smart Grid ................................................................. 24
7.1.1 General......................................................................................................................... 24
7.1.2 Definition....................................................................................................................... 24
7.1.3 Interoperability Categories ............................................................................................ 24
7.2 SGAM Framework Elements ............................................................................................. 26
7.2.1 General......................................................................................................................... 26
7.2.2 SGAM Interoperability Layers ....................................................................................... 26
7.2.3 SGAM - Smart Grid Plane ............................................................................................. 27
7.2.4 SGAM Domains ............................................................................................................ 28
7.2.5 SGAM Zones ................................................................................................................ 29
7.2.6 SGAM Framework ........................................................................................................ 30
7.2.7 Cross-cutting Issues and SGAM ................................................................................... 31
7.3 The SGAM methodology ................................................................................................... 33
7.3.1 General......................................................................................................................... 33
7.3.2 Principles ...................................................................................................................... 33
7.3.3 Mapping of use cases to SGAM framework .................................................................. 34
7.3.4 Mapping the business layer with the lower SGAM layers .............................................. 36
8 Reference Architecture Elements ....................................................................................... 38
8.1 Business Architecture........................................................................................................ 38
8.1.1 Roles & actors .............................................................................................................. 40
8.1.2 Business Functions....................................................................................................... 40
8.1.3 Business Services ........................................................................................................ 41

2
 8.1.4 Business Processes ..................................................................................................... 41
8.1.5 Methodology/ Process .................................................................................................. 41
8.2 Functional Architecture ...................................................................................................... 43
8.2.1 General......................................................................................................................... 43
8.2.2 Functional Architecture Meta-model.............................................................................. 43
8.2.3 Smart Grid Functional Architecture ............................................................................... 44
8.3 Information Architecture .................................................................................................... 46
8.3.1 General......................................................................................................................... 46
8.3.2 Integration technology................................................................................................... 46
8.3.3 Data Models ................................................................................................................. 47
8.3.4 Interfaces ...................................................................................................................... 48
8.3.5 Logical interfaces .......................................................................................................... 49
8.4 Communication Architecture ............................................................................................. 50
8.4.1 Recommendations ........................................................................................................ 50
8.4.2 Smart Grid sub-networks .............................................................................................. 51
8.4.3 Applicability statement of the Communication Technologies to the Smart Grid
Sub-networks ................................................................................................................ 54
Annex A Background Architecture Work .................................................................................... 56
A.1 Objectives of this annex .................................................................................................... 56
A.1.1 Aspects of a Common View: evolvability, simplicity and reuse of building blocks .......... 56
A.1.2 Clarification of views: power vs. communication; applications vs. services ................... 57
A.2 Relationship to existing Architectures ................................................................................ 58
A.3 Overview of one possible RA lifecycle-model .................................................................... 58
Annex B Model mappings ............................................................................................................ 60
B.1 Conceptual Model ............................................................................................................. 60
B.2 SGAM Framework ............................................................................................................. 60
B.2.1 Quality of interoperability .............................................................................................. 60
B.2.2 Specific qualities of interoperability: ―Plug-and-play‖ and ―Interchangeability‖ ............... 61
B.2.3 Standard profiles – a measure to increase the quality of interoperability ....................... 61
B.2.4 SGAM Mapping Example .............................................................................................. 61
B.2.4.1 Use Case Analysis ................................................................................................... 61
B.2.4.2 Development of the Component Layer .................................................................... 67
B.2.4.3 Development of the Business Layer ........................................................................ 68
B.2.4.4 Development of the Function Layer .......................................................................... 69
B.2.4.5 Development of the Information Layer ...................................................................... 70
B.2.4.6 Development of the Communication Layer ............................................................... 72
B.2.5 Relation of SGAM framework to Architecture Standards ............................................... 73
B.2.6 Examples and Mappings of existing solutions ............................................................... 78
B.2.6.1 Example: ETSI ―M2M Architecture‖ .......................................................................... 79
B.2.6.2 Example: IEC SG3 ―Mapping Chart‖......................................................................... 79
B.2.6.3 Example: IEC TC57 ―RA for Power System Information Exchange‖ ......................... 80
B.2.7 Findings ........................................................................................................................ 81
B.2.8 Mapping of business transactions ................................................................................. 81
Annex C Business Architecture and Conceptual Model ............................................................ 83
C.1 Conceptual Model ............................................................................................................. 83
C.1.1 Introduction ................................................................................................................... 83
C.1.2 Historical context .......................................................................................................... 84
C.1.3 Starting Principles ......................................................................................................... 86
C.1.4 European Conceptual Model of Smart Grids ................................................................. 88
C.1.4.1 Alternative Figure: European Conceptual Model for the Smart Grid ......................... 90
C.1.5 Alignment...................................................................................................................... 91
C.1.5.1 Alignment with the EU flexibility concept .................................................................. 91
C.1.5.2 Alignment with SG-CG/SP on Sustainable Processes ............................................. 92
C.1.5.3 Alignment with NIST, SGIP, SGAC .......................................................................... 92
C.1.5.4 Alignment with Harmonized Electricity Market Role Model ....................................... 92

3
 C.1.5.5 Alignment with EU market model developments (EG3) ............................................ 93
C.1.6 Conclusions .................................................................................................................. 93
C.2 The European Harmonized Electricity Market Role Model ................................................. 93
C.2.1 Role model – role definitions ......................................................................................... 94
C.3 Relationship between the domains of the conceptual model and the European
harmonized electricity market role model .......................................................................... 98
C.4 Relation between the flexibility operator actor and the European harmonized
electricity market role model .............................................................................................. 99
C.4.1 Communication of price signals, tariffs and other economic incentives ....................... 100
C.4.2 Explicit trade in flexibility in demand and/or supply ..................................................... 101
C.4.3 Direct control of demand and/or supply ....................................................................... 101
Annex D Functional Architecture............................................................................................... 102
Annex E Information Architecture ............................................................................................. 103
Annex F Communication Architecture ...................................................................................... 106
Annex G Bibliography ................................................................................................................ 107

History of document
Number Date Content
v0.5 24/01/2012 First TR external version for SG-CG ―Sanity Check‖
v1.0 02/03/2012 First Interim TR draft for official comments
v2.0 31/07/2012 Second interim TR draft for official comments
v3.0 08/11/2012 Final TR for adoption by M/490

Main changes in this version

The adoption of the SG-CG report template has induced a reordering and renumbering of most of
the sections and annexes.

The changes between version 2.0 and 3.0 have been kept minimal, considering that this version
was not to be reviewed.

However, Annex C has been largely changed. A lot of new work has been done within SG-CG/RA
between TR2.0 and TR3.0 on the Conceptual Model. Considering that is was useful to the readers,
even if it could not be introduced in the main section of the report because of the many
uncommented changes, it has been decided to present it as an informative reference.

In addition, Annex F (Communication Architecture) has been largely changed and is provided as a
separate document, as in the previous versions of this report.

4
Foreword

Based on the content of the M/490 EU Mandate, the general scope of work on Standardization of
the Smart Grid might be considered as follows:

CEN, CENELEC, and ETSI are requested to develop a framework to enable European
Standardization Organizations to perform continuous standard enhancement and development
in the field of Smart Grids, while maintaining transverse consistency and promote continuous
innovation.

The expected framework will consist of a set of deliverables. The deliverable addressed in this
document is:

―A technical reference architecture, which will represent the functional information data flows
between the main domains and integrate several systems and subsystems architectures.‖

The development of this technical Reference Architecture, under the form of a Technical Report
(TR), is the main responsibility of the Reference Architecture Working Group (SG-CG/RA), working
under the Smart Grid Coordination Group (SG-CG) established by CEN, CENELEC and ETSI in
order to fulfill the tasks laid down the Mandate M/490 of the European Commission.

The members of the Reference Architecture WG have been nominated, following an official call for
experts. They have met since June 2011 in order to produce the various versions of the Technical
Report. A Work Programme has been set-up that involves the production of several versions of the
TR until final completion.

A first version v0.5 has been circulated in January 2012 for ―Sanity check‖ within the SG-CG, to get
guidance on the main aspects of the report.

The version v1.0 was the first Interim Report. It was a first solid step towards the Reference
Architecture and has initiated a discussion about the architectural model proposed as well as its
different viewpoints and dimensions.

The version v2.0 was the second Interim Report. It has been developed on the basis of the
feedback (over 340 comments) received on v1.0 and on new contributions from the SG-CG/RA
team.

The version v3.0 (this document) is the final version of the report within the current iteration of the
M/490 mandate. It will be handed over to the European Commission in November 2012 and sent
for approval by CEN, CENELEC and ETSI.

Further work on this report is expected in a subsequent iteration of the M/490 mandate, still to be
decided.

5
1 Scope
This document is prepared by the Smart Grid Coordination Group (SG-CG) Reference Architecture
Working Group (SG-CG/RA) and addresses the M/490 mandate‘s deliverable regarding the
technical reference architecture.

This report is the final report due at the end of 2012.

1.1 How to use the document

The overall content of this document is as follows.

Chapter 1 (this chapter) introduces the approach chosen by the SG-CG/RA to address a complex
problem space and the corresponding choices to define the scope of work. It outlines the main
outcome expected at the end of the work and clarifies what is the main (but by far not the only)
audience for the report. It also briefly outlines what is not in the scope of the SG-CG/RA work.

Chapters 2, 3 and 4 provide background information to the report (References, etc.) whenever they
are not common to all SG-CG Reports.

Chapter 5 is an Executive Summary which is reproduced as such in the overall M/490 Framework
Document.

Chapter 6 provides the European view of the Smart Grids Conceptual Model and an overview of
the general elements of a Reference Architecture. It introduces the viewpoints chosen as target of
the SG-CG/RA work.

Chapter 7 introduces the Smart Grids Architecture Model (SGAM) framework. The SGAM
introduces interoperability aspects and how they are taken into account via a domain, zone and
layer based approach. It finally introduces the methodology associated with the SGAM. Taking into
account the interoperability dimension, the SGAM is a method to fully assign and categorize
processes, products and utility operations and align standards to them.

Chapter 8 outlines the main elements of the different architectural viewpoints chosen for
development by the SG-CG/RA, i.e. the Business, Functional, Information and Communication
Architectures. Additional material or more detailed presentations of these architectures are
provided in Annexes (that can be separate documents if their size requires it).

Chapter 1 lists the work items that SG-CG/RA may address in view of the next iteration of the
M/490 mandate.

Annex A is grouping all the background work that serves as a foundation to the SG-CG/RA Report
but was deemed not essential to the understanding of the Reference Architecture principles.

Annex B provides an overview how the SG-CG Sustainable Processes Work Group‘s Use Cases
can be applied alongside the SGAM model, providing a holistic architectural view comprising the
most important aspects for Smart Grid operations. In particular, it contains a detailed example
regarding the application of the SGAM Methodology to a generic Smart Grid use case.

Annexes C to F provide details of the Reference Architecture viewpoints.

1.2 Approach to the problem domain

Considering that the overall scope of an architectural description can be quite large, the SG-
CG/RA has chosen to focus on the following aspects of the reference architecture:

6
  Means to communicate on a common view and language about a system context, not only
in the SG-CG but also with industry, customers and regulators;
 Integration of various existing state-of-the-art approaches into one model with additional
European aspects;
 Methods to serve as a basis to analyze and evaluate alternative implementations of an
architecture;
 Support for planning for transition from an existing legacy architecture to a new smart grid-
driven architecture;
 Criteria for properly assessing conformance with identified standards and given
interoperability requirements.

This has led the SG-CG/RA to address three major objectives:

 Ensuring that the main elements of the architectural model be able to represent the Smart
Grid domain in an abstract manner with all the major stakeholders. Such a model should be
coherent with already existing comparable models worldwide.
 Define an architectural framework that would support a variety of different approaches
corresponding to different stakeholders‘ requirements and make it in a timeframe that would
force to choose a limited set of such approaches.
 Providing a methodology that would allow the users of the architectural model to apply it to
a large variety of use cases so that, in particular, it would provide a guide to analyze
potential implementation scenarios, identify areas of possible lack of interoperability (e.g.
missing Standards), etc.

Regarding the first objective, the NIST Conceptual Model [NIST 2009] was considered as a first
essential input, though it required adaptation to the European context and some of its specific
requirements (identified by prior work of the European Smart Grid Task Force).

Completion of the second objective required a careful selection of the architecture viewpoints to be
developed. In general, reference architectures aim at providing a thorough view of many aspects of
a system viewed by the different participating stakeholders throughout the overall system lifecycle.
This means that, on a complex system like the Smart Grid, it is not always possible to cover all
viewpoints and choices had to be made.

In particular, the viewpoints had to be chosen in order to allow for a meaningful description of
relevant and essential aspects of the system (e.g. intended use and environment, principles,
assumptions and constraints to guide future change, points of flexibility or limitations), documenting
architectural decisions with their rationales, limitations and implications.

The third objective was reached through the provision of a model that would make the link between
the different architecture viewpoints and that could be used in a systematic manner, thus leading to
the provision of a methodology.

1.3 Outcome: an architecture framework and a mapping methodology

This report addresses the technical reference architecture part of mandate M/490 and provides the
main results below:
European Conceptual Model. It is an evolution of the NIST model in order to take into
account some specific requirements of the EU context that the NIST model did not address.
The major one is the integration of ―Distributed Energy Resources‖ (DER).

Architecture Viewpoints. They represent a limited set of ways to represent abstractions of

different stakeholders‘ views of a Smart Grid system. The viewpoints selected are the
Business, Functional, Information, Communication viewpoints.

Smart Grids Architecture Model (SGAM) Framework. The architecture framework takes into
account already identified relevant aspects [JWG-SG 2010] like interoperability (e.g. the

7
 GridWise Architecture Council (GWAC) Stack), multi-viewpoints (SGAM Layers).
Additionally, a functional classification, overview on needed and existing data models,
interfaces and communication layers and requirements is provided to the First Set of
Standards Work Group (FSSWG).

This framework can be applied, as a mapping methodology, to document smart grid use cases
(developed by the Sustainable Processes Work Group - SG-CG/SP) from a technical, business,
standardization and security point-of-view (as developed with the Smart Grids Information Security
Work Group - SG-CG/SGIS) and identify standards gap.

1.4 Main target audience: Standardization Technical Committees

The target audience of the reference architecture is mainly standardization bodies and technical
groups which can use the architectural framework, the methodological guidelines as well as the
mappings of existing architectures (developed in the report annexes) to guide their work.

The SGAM provides a holistic view on the most important existing standards and architectures
from different SDOs, making this deliverable a valuable document for members of standardization
dealing with Smart Grid standards.

1.5 What is not in the scope of this document

For a variety of reasons, the work of SG-CG/RA shall not address notably the following domains:
 Standards development; Certification
 Market Models
 Regulation issues
 Home Automation, Building, …
 Gas

8
2 References
Smart Grids Coordination Group Documents

[SG-CG/A] SG-CG/M490/A Framework for Smart Grid Standardization

[SG-CG/B] SG-CG/M490/B_ Smart Grid First set of standards
[SG-CG/C] SG-CG/M490/C_ Smart Grid Reference Architecture (this document)
[SG-CG/D] SG-CG/M490/D_Smart Grid Information Security
[SG-CG/E] SG-CG/M490/E_Smart Grid Use Case Management Process

References made in the main part of this document

[ENTSO-E 2011] The Harmonized Electricity Market Role Model (December 2011), ENTSO-
E, online: https://www.entsoe.eu/fileadmin/user_upload/edi/library/role/role-
model-v2011-01.pdf.
[ENTSO-E 2012] ‗Modular Development Plan of the Pan-European Transmission System
2050‘ of the e-HIGHWAY2050 Project Consortium:
https://www.entsoe.eu/system-development/2050-electricity-highways/
[GWAC2008] GridWise Interoperability Context-Setting Framework (March 2008),
GridWise Architecture Council, online: www.gridwiseac.org/pdfs/.
[IEEE2030-2011] IEEE Guide for Smart Grid Interoperability of Energy Technology and
Information Technology Operation, with the Electric Power System (EPS),
End-Use Applications, and Loads, IEEE Std. 2030 (2011).
[IEC61850-2010] IEC 61850, Communication networks and systems for power utility
automation, 2010.
[IEC62357-2011] IEC 62357-1, TR Ed.1: Reference architecture for power system
information exchange, 2011.
[IEC62559-2008] IEC 62559, PAS Ed.1: Intelligrid Methodology for developing requirements
for Energy Systems
[IEC 62264-2003] IEC 62262, Enterprise-control system integration
[ISO/IEC42010] ISO/IEC 42010: Systems Engineering – Architecture description, 2011
[JWG-SG 2011] JWG Smart grids: Final report: JWG report on standards for smart grids –
V1.1
[NIST2009] NIST Framework and Roadmap for Smart Grid Interoperability,
Interoperability Standards Release 1.0 (2009), Office of the National
Coordinator for Smart Grid Interoperability, National Institute of Standards
and Technology, U.S. Department of Commerce. Online:
www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf
[NIST 2012] Framework and Roadmap for Smart Grid Interoperability, Interoperability
Standards Release 1.0 (2009), Office of the National Coordinator for Smart
Grid Interoperability, National Institute of Standards and Technology, U.S.
Department of Commerce. Online:
www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf

References made in the Annexes of this document

It should be noted that the SG-CG First Set of Standards Work Group report [SG-CG/B] provides a
list of references that may include most of the references below. In case of doubt on the applicable
referenced documents, the [SG-CG/B] list prevails.

9
The following references are made in Annex E:
Mapping of IEC 61850 Common Data Classes on IEC 60870-5-104 (IEC 61850-80-1 TS)
OASIS EMIX
UN/CEFACT CCTS
EN 60870-6-802:2002 + A1:2005, Telecontrol equipment and systems – Part 6-802:
Telecontrol protocols compatible with ISO standards and ITU-T recommendations –
TASE.2 Object models
EN 60870-5-1:1993, Telecontrol equipment and systems – Part 5: Transmission protocols –
Section 1: Transmission frame formats
EN 60870-5-3:1992, Telecontrol equipment and systems – Part 5: Transmission protocols –
Section 3: General structure of application data
IEC 61850-7-410 Ed. 1.0, Communication networks and systems for power utility
automation – Part 7-410: Hydroelectric power plants – Communication for monitoring and
control
IEC 61850-7-420, Communication networks and systems for power utility automation – Part
7-420: Basic communication structure – Distributed energy resources logical nodes
IEC 61400-25-2, Communications for monitoring and control of wind power plants – Part
25-2: Information models
IEC 61400-25-3, Communications for monitoring and control of wind power plants – Part
25-3: Information exchange models
IEC 61400-25-6, Communications for monitoring and control of wind power plants – Part
25-6 Communications for monitoring and control of wind power plants: Logical node
classes and data classes for condition monitoring
IEC 62056 series, Electricity metering – Data exchange for meter reading, tariff and load
control, Parts 21, 31, 41, 42, 46, 47, 51, 52, 53, 61, 62
IEC 61334, Distribution automation using distribution line carrier systems – Part 4 Sections
32, 511, 512, Part 5 Section 1
EN 61970-301:2004, Energy management system application program interface (EMS-API)
– Part 301: Common information model (CIM) base
EN 61970-402:2008 Ed. 1.0, Energy management system application program interface
(EMS- API) – Part 402: Component interface specification (CIS) – Common services
EN 61970-403:2007, Energy management system application interface (EMS- API) – Part
403: Component Interface Specification (CIS) – Generic Data Access
EN 61970-404:2007, Energy management system application program interface (EMS-API)
– Part 404: High Speed Data Access (HSDA))
EN 61970-405:2007, Energy management system application program interface (EMS-API)
– Part 405: Generic eventing and subscription (GES)
EN 61970-407:2007, Energy management system application program interface (EMS-API)
– Part 407: Time series data access (TSDA)
EN 61970-453:2008, Energy management system application interface (EMS- API) – Part
453: CIM based graphics exchange
EN 61970-501:2006, Energy management system application interface (EMS- API) – Part
501: Common information model resource description framework (CIM RDF) Schema
EN 61968-:2004, Application integration at electric utilities – System interfaces for
distribution management – Part 3: Interface for network operations
EN 61968-4:2007, Application integration at electric utilities – System interfaces for
distribution management – Part 4: Interfaces for records and asset management
EN 61968-9:2009, System Interfaces For Distribution Management – Part 9: Interface
Standard for Meter Reading and Control
FprEN 61968-11:2010, System Interfaces for Distribution Management – Part 11:
Distribution Information Exchange Model
EN 61968-13:2008, System Interfaces for distribution management – CIM RDF Model
Exchange Format for Distribution

10
 IEC 61850-5 Ed. 1.0, Communication networks and systems in substations – Part 5:
Communication requirements for functions and device models
IEC 61850-6 Ed. 1.0, Communication networks and systems in substations – Part 6:
Configuration description language for communication in electrical substations related to
IEDs
IEC 61850-7-1 Ed. 1.0, Communication networks and systems in substations – Part 7-1:
Basic communication structure for substation and feeder equipment – Principles and
models
IEC 61850-7-2 Ed. 1.0, Communication networks and systems in substations – Part 7-2:
Basic communication structure for substation and feeder equipment – Abstract
communication service interface (ACSI)
IEC 61850-7-3 Ed. 1.0, Communication networks and systems in substations – Part 7-3:
Basic communication structure for substation and feeder equipment – Common data
classes
IEC 61850-7-4 Ed. 1.0, Communication networks and systems in substations – Part 7-4:
Basic communication structure for substation and feeder equipment – Compatible logical
node classes and data classes
IEC 62325-301 Ed.1.0 : Common Information Model Market Extensions
IEC 62325-501 Framework for energy market communications - Part 501: General
guidelines for use of ebXML
IEC 62325-351 Framework for energy market communications - Part 351: CIM European
Market Model Exchange Profile
IEC 62325-502 Framework for energy market communications - Part 502: Profile of ebXML

Other references pertaining to Communication Architecture are made in Annex F.

3 Terms and definitions

Architecture
Fundamental concepts or properties of a system in its environment embodied in its elements,
relationships, and in the principles of its design and evolution [ISO/IEC42010].

Architecture Framework
Conventions, principles and practices for the description of architectures established within a
specific domain of application and/or community of stakeholders [ISO/IEC42010].

Conceptual Model
The Smart Grid is a complex system of systems for which a common understanding of its
major building blocks and how they interrelate must be broadly shared. NIST has developed a
conceptual architectural reference model to facilitate this shared view. This model provides a
means to analyze use cases, identify interfaces for which interoperability standards are
needed, and to facilitate development of a cyber security strategy. [NIST2009]

Interoperability
Interoperability refers to the ability of two or more devices from the same vendor, or different
vendors, to exchange information and use that information for correct co-operation [IEC61850-
2010].

Reference Architecture
A Reference Architecture describes the structure of a system with its element types and their
structures, as well as their interaction types, among each other and with their environment.
Describing this, a Reference Architecture defines restrictions for an instantiation (concrete
architecture). Through abstraction from individual details, a Reference Architecture is universally
valid within a specific domain. Further architectures with the same functional requirements can be

11
constructed based on the reference architecture. Along with reference architectures comes a
recommendation, based on experiences from existing developments as well as from a wide
acceptance and recognition by its users or per definition. [ISO/IEC42010]

SGAM Interoperability Layer

In order to allow a clear presentation and simple handling of the architecture model, the
interoperability categories described in the GridWise Architecture model are aggregated in SGAM
into five abstract interoperability layers: Business, Function, Information, Communication and
Component.

SGAM Smart Grid Plane

The Smart Grid Plane is defined from the application to the Smart Grid Conceptual Model of the
principle of separating the Electrical Process viewpoint (partitioning into the physical domains of
the electrical energy conversion chain) and the Information Management viewpoint (partitioning
into the hierarchical zones (or levels) for the management of the electrical process. [IEC62357-
2011, IEC 62264-2003]

SGAM Domain
One dimension of the Smart Grid Plane covers the complete electrical energy conversion chain,
partitioned into 5 domains: Bulk Generation, Transmission, Distribution, DER and Customers
Premises.

SGAM Zone
One dimension of the Smart Grid Plane represents the hierarchical levels of power system
management, partitioned into 6 zones: Process, Field, Station, Operation, Enterprise and Market
[IEC62357-2011].

4 Symbols and abbreviations

Acronyms
3GPP 3rd Generation Partnership Project
6LoWPAN IPv6 over Low power Wireless Personal Area Networks
ADSL Asymmetric digital subscriber line
AN Access Network
ANSI American National Standard Institute
ASHRAE American Society of Heating, Refrigerating and Air-Conditioning
BCM Business Capability Model
CEN Comité Européen de Normalisation.
CENELEC Comité Européen de Normalisation Electrotechnique
CIM Common Information Model
DER Distributed Energy Resources
DSO Distribution System Operator
eBIX (European forum for) energy Business Information Exchange
EGx EU Smart Grid Task Force Expert Group x (1 to 3)
ENTSO-E European Network of Transmission System Operators for Electricity
ESCO Energy Service Company
eTOM extended Telecom Operations Map
ETSI European Telecommunications Standard Institute
EV Electrical Vehicle
EVO Electrical Vehicle Operator
FACTS Flexible Alternating Current Transmission Systems
FLISR Fault Location Isolation and Service Recovery
GSM Global System for Mobile
GWAC GridWise Architecture Council
HAN Home Area Network

12
HDSL High-bit-rate digital subscriber line
HSPA High Speed Packet Access
ICT Information & Communication Technology
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IP Internet Protocol
IPv6 Internet Protocol Version 6
ISO International Organization for Standardization
ITU-T: International Telecommunications Union for the Telecommunication
Standardization Sector
JWG Joint Working Report for Standards for the Smart Grids
KNX EN 50090 (was Konnex)
L2TP Layer 2 Tunneling Protocol
LR WPAN Low Rate Wireless Personal Area Network
LTE Long Term Evolution
MAC Media Access Control
MPLS Multiprotocol Label Switching
MPLS-TP MPLS Transport Profile
NAN Neighborhood Area Network
NAT Network Address Translator
OSI: Open System Interconnection
OTN Optical Transport Network
PLC Power Line Carrier
PLC Power Line Communication
PON Passive Optical Network
QoS Quality of Service
RPL Routing Protocol for Low power and lossy networks (LLN)
SDH Synchronous Optical Networking
SDO Standards Developing Organization
SG-CG Smart Grids Coordination Group
SG-CG/FSS SG-CG First Set of Standards Work Group
SG-CG/RA SG-CG Reference Architecture Work Group
SG-CG/SP SG-CG Sustainable Processes Work Group
SLA Service Level Agreement
TDM Time Division Multiplexing
TMF TeleManagement Forum
TOGAF The Open Group Architecture Framework
TSO Transmission System Operator
UMTS Universal Mobile Telecommunications System
WAN Wide Area Network
WAMS Wide Area Management Systems
WAN Wide Area Network
WASA Wide Area Situation Awareness
WPAN Wireless Personal Area Network
xDSL Digital Subscriber Line
XG-PON 10G PON

13
5 Executive Summary
The ―SG-CG/M490/C_ Smart Grid Reference Architecture‖ report prepared by the Reference
Architecture Working Group (SG-CG/RA) addresses the M/490 mandate deliverable regarding the
development of a Technical Reference Architecture.

The Reference Architecture challenge

The CEN/CENELEC/ETSI Joint Working Group report on standards for smart grids has defined the
context for the development of the Smart Grids Reference Architecture (RA):

―It is reasonable to view [the Smart Grid] as an evolution of the current grid to take into account
new requirements, to develop new applications and to integrate new state-of-the-art
technologies, in particular Information and Communication Technologies (ICT). Integration of
ICT into smart grids will provide extended applications management capabilities over an
integrated secure, reliable and high-performance network.

This will result in a new architecture with multiple stakeholders, multiple applications, multiple
networks that need to interoperate: this can only be achieved if those who will develop the
smart grid (and in particular its standards) can rely on an agreed set of models allowing
description and prescription: these models are referred to in this paragraph as Reference
Architecture.‖

To develop a coherent and useful Reference Architecture, two main issues have been addressed:

Clarification of the requirements for the reference architecture and description of its major
elements. Reuse of existing results has been considered essential to a fast progress. In
particular, the Reference Architecture elements are positioned with respect to existing
models (e.g. NIST) and architectural frameworks (GWAC, TOGAF, etc.). Extensions have
been limited and, in general, focused on addressing the European specificities.

Coherence of the RA with respect to the overall Smart Grids standardization process.
Notably, the work of SG-CG/RA has been aligned with the other SG-CG Work Groups.
• Using upstream results of SG-CG/SP on (generic) use cases and the flexibility concept;
• Providing results to SG-CG/FSS regarding the identification of useful standards and a
method to support standards gap analysis;
• Clarifying the alignment with SG-CG/SGIS regarding the representation of the Security
viewpoint in the RA and providing a method to analyze Information Security use cases.
In addition, alignment with existing initiatives from other organizations (e.g. NIST, ENTSO-
E, EU Task Force Experts Groups …) has been a constant objective.

Main elements of the Reference Architecture

The main components of the Reference Architecture are now in place. The most important are
described below.
European Conceptual Model
The National Institute of Standards and Technology (NIST) has introduced the Smart Grid
Conceptual Model which provides a high-level framework for the Smart Grid that defines seven
high-level domains and shows all the communications and energy/electricity flows connecting each
domain and how they are interrelated.

Though the NIST model is a sound and recognized basis, it has been necessary to adapt it in order
to take into account some specific requirements of the EU context that the NIST model did not
address. Two main elements are introduced to create the EU Conceptual Model. The first one is
the Distributed Energy Resource (DER) domain that allows addressing the very important role that

14
DER plays in the European objectives. The second one is the Flexibility concept (developed in SG-
CG/SP) that group consumption, production and storage together in a flexibility entity.

The EU Conceptual Model is a top layer model (or master model) and will also act as a bridge
between the underlying models in the different viewpoints of the Reference Architecture.

During the course of this first iteration of the M/490 mandate, a constant discussion has taken
place with NIST SGIP/SGAC to ensure optimal alignment on the Conceptual Model. The model
that is presented in the main part of the SG-CG/RA report is reflecting these discussions.
Smart Grids Architecture Model (SGAM) Framework
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).
SGAM Methodology
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. The model
has largely evolved in v2.0, with clearer basic definitions, more detailed presentation of the
elements (zones, domains, etc.), a clarification of the methodology and a complete detailed
example.
Architecture Viewpoints
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:
The Business Architecture is addressed from a methodology point of view, in order to
ensure that whatever market or business models are selected, the correct business
services and underlying architectures are developed in a consistent and coherent way;
The Functional Architecture provides a meta-model to describe functional architectures and
gives an architectural overview of typical functional groups of Smart Grids (intended to
support the high-level services that were addressed in the Smart Grids Task Force EG1);
The Information Architecture addresses the notions of data modeling and interfaces and
how they are applicable in the SGAM model. Furthermore, it introduces the concept of
―logical interfaces‖ which is aimed at simplifying the development of interface specifications
especially in case of multiple actors with relationships across domains;
The Communication Architecture deals with communication aspects of the Smart Grid,
considering generic Smart Grid use cases to derive requirements and to consider their
adequacy to existing communications standards in order to identify communication
standards gaps. It provides a set of recommendations for standardization work as well as a
view of how profiling and interoperability specifications could be done.

How to use the Reference Architecture

Given the large span of the Reference Architecture components described above, the Reference
Architecture can be used in a variety of ways, amongst which:
Adaption of common models and meta-models to allow easier information sharing between
different stakeholders in pre-standardization (e.g. research projects) and standardization;

15
 Analysis of Smart Grids use cases via the SGAM methodology. This is a way to support,
via an easier analysis of different architectural alternatives, the work of those who are going
to implement those use cases;
Gap analysis: analysis of generic use cases in order to identify areas where appropriate
standards are missing and should be developed in standardization;
…

Outlook
The current version of the Reference Architecture document is the result of the work done by the
SG-CG/RA Working Group during the first iteration of the M/490 Mandate.

The final version (v3.0) of this report addresses the comments made on v2.0 and clarifies some of
the remaining issues, such as the handling of Security aspects in the Architecture and in SGAM,
an (SG-CG) agreed functional meta-model, or the respective role of markets and business
viewpoints.

However, there are still areas where the document can be completed such as a role-based
definition of the European Conceptual Model (developed but still to be validated), expansion of the
Functional Architecture, more in-depth exploration of the communication profiles, etc. This work
could be addressed if the extension of the M/490 Mandate for a second iteration is decided.

16
6 Conceptual Model and Reference Architecture Principles
6.1 Motivation for Conceptual Model and Reference Architecture
Smart Grids standardization is not a green field. It is largely relying on previous work done at
national, regional (in particular European) and international level, both on standardization (largely
focused on the identification of the existing set of standards that are applicable to the Smart Grid)
and on pilot and research project (that validate early ideas that may be brought to standardization).

The work of the Reference Architecture WG will, in particular, use significant existing material such
as the NIST Conceptual Model [NIST 2009], the GridWise Architecture Council Stack
interoperability categories [GWAC 2008], architecture standards like TOGAF and Archimate
[Jonkers 2010].

The development of the SG-CG framework (as already noted above in section 5) addresses
‗continuous standard enhancement and development in the field of Smart Grids, while maintaining
transverse consistency and promote continuous innovation‘.

To achieve consistency and gradual integration of innovation in an incremental manner, two

elements are deemed essential, that are both addressed by the SG-CG/RA:
 An overall high-level model that describes the main actors of the Smart Grid and their main
interactions. This is captured by the Conceptual Model. The approach taken by the SG-
CG/RA, considering the need to reuse existing models whenever possible, has been to
take into account the NIST Conceptual Model, analyze which differences a European
approach would need to bring to it and further reduce these differences as much as
possible;
 A set of universal presentation schema that allow for the presentation of the Smart Grid
according to a variety of viewpoints that can cope with
o The variety of Smart Grid stakeholders,
o The need to combine power system management requirements with expanded
interoperability requirements, and
o The possibility to allow for various levels of description from the top-level down to
more detailed views.
This is captured in the Reference Architecture that should be seen as the aggregation of
several architectures (e.g. functional, communication, etc.) into a common framework.

The motivation for the creation and utilization of reference architectures can be to have a blueprint
for the development of future systems and components, providing the possibility to identify gaps in
a product portfolio. It can also be used to structure a certain Smart Grid domain and provide a
foundation for communication about it to other domains which need to interoperate. Furthermore, it
can be used to document decisions which have been taken during the development process of an
infrastructure.

An additional – and important - motivation for the SG-CG/RA was to ensure that the Reference
architecture could help, by providing an appropriate methodology to identify where standardization
gaps may exist.

It is also important to finally point out a very essential motivation for the Reference Architecture
work: reuse as much of the existing work as possible and not re-invent the wheel. This has guided
both the Conceptual Model (as noted above) as well as the Reference Architecture.

6.2 Requirements for the M/490 Reference Architecture

The reference architecture has to be very much in consistency with the following aspects and
requirements already outlined in this report.

17
It must support the work of Smart Grids standardization over a long period of time:
 Be able to represent the current situation (snapshot of already installed basis and
reference architectures)
 Be able to map future concepts (migration and gap analysis)
 Achieve a common understanding of stakeholders
 Fulfill the demand for systematic coordination of Smart Grid standardization from an
architectural perspective
 Provide a top-level perspective encompassing entire smart grid but enabling
enlargements to details
 Be able to be represented using established and state-of-the art System Engineering
technology and methodologies (e.g. lifecycle model, architecture standards and methods)
 Take into account Standardization activities (regional, Europe, international)
 Be able to reflect European Pilot and research projects (regional, Europe, international)

More specifically, the Reference Architecture must be able to address the complexity of the Smart
Grid in a coherent manner:
 Be consistent with the M/490 conceptual model;
 Fulfill the need for an universal presentation schema – a model, allowing to map
stakeholder specific prospective in a common view
 Being able to represent the views of different stakeholders (not only SDOs) in an
universal way , e.g. provide some of the following viewpoints in an abstract way:
Enterprise viewpoint,
Information viewpoint,
Computational viewpoint,
Engineering viewpoint,
Technology Viewpoint (RM-ODP, ISO/IEC 10746)
Business Architecture viewpoint,
Application Architecture viewpoint,
Data Architecture viewpoint,
Technology Architecture viewpoint
 Be consistent with established interoperability categories and experiences
 Provide an abstract view on SG specific structures (domains, zones, layers)
 Fulfill the need for an universal presentation schema – a model, allowing to map
stakeholder specific prospective in a common view

6.3 Conceptual Model

This section will present the Conceptual Model practically unchanged since the draft version 2.0 of
the Reference Architecture report.

Nevertheless, a lot of new work has been done within SG-CG/RA between TR2.0 and TR3.0 on
the Conceptual Model, in order to better support the flexibility concept and to take into account the
comments made on version 2.0. A new version of this section has been produced but it could not
be introduced in the main section of the report because of the many uncommented changes.
Consequently, it has been decided to present it as an informative reference in Annex C, section
C.1. It is expected that this new section will be introduced in the subsequent versions of this report,
should the new M/490 iteration be decided.

6.3.1 Introduction
The electrical energy system is currently undergoing a paradigm change, that has been affected by
a change from the classical centralistic and top down energy production chain "Generation",
"Transmission", "Distribution" and "Consumption" to a more decentralized system, in which the
participants change their roles dynamically and interact cooperative. The development of the
concepts and architectures for a European Smart Grid is not a simple task, because there are
various concepts and architectures, representing individual stakeholders‘ viewpoints.

18
The National Institute of Standards and Technology (NIST) has introduced the Smart Grid
Conceptual Model which provides a high-level framework for the Smart Grid that defines seven
high-level domains (Bulk Generation, Transmission, Distribution, Customers, Operations, Markets
and Service Providers) and shows all the communications and energy/electricity flows connecting
each domain and how they are interrelated. Each individual domain is itself comprised of important
smart grid elements (actors and applications) that are connected to each other through two-way
communications and energy/electricity paths. The NIST Conceptual Model helps stakeholders to
understand the building blocks of an end-to-end smart grid system, from Generation to (and from)
Customers, and explores the interrelation between these smart grid segments.

In order to develop the different viewpoints in an aligned and consistent manner, the EU
Conceptual Model is introduced. It is based on the NIST Model which is used with some
customizations and extensions regarding the general European requirements. This EU Conceptual
Model forms the top layer model or master model and it is therefore the bridge between models
from different viewpoints. Its task is to form a bracket over all sub models.

6.3.2 Approach and Requirements

The electrical power grid in the European Union is based on a big number of heterogeneous
participants; that are hierarchically and next to each other connected. Every participant of the
electrical power grid builds and operates its part of the network in its own manner; and at the same
time they have to work together. So the EU Conceptual Model has to deal with different levels of
decentralization (see Figure 1). The figure shows still another effect. Regarding to the history of
electrical power supply systems, the electrical power supply started more than a century ago with
decentralized isolated networks and developed to an European centralized mixed network. With
the beginning of the 21st century, more and more decentralized energy systems are coming into
the network again, so future architectures will have to support both centralized and decentralized
concepts. Consequently requirements for distributed and centralized concepts and applications
need to be considered. . From this follows the requirement to the EU conceptual model to allow to
model different levels of decentralization between the two extremes: ―Fully Centralized Energy
System‖ and ―Fully Decentralized Energy System‖.

Figure 1: Different levels of decentralization

19
6.3.3 An EU extension of the NIST Model
To integrate the ―Distributed Energy Resources‖ (DER) into the NIST Model, it will be extended by
a new ―Distributed Energy Resources‖ Domain, which is (in terms of electricity and
communications) connected with the other NIST Domains shown in Figure 2.

The extension of the NIST Model with a new DER Domain is necessary for the following reasons:
Distributed Energy Resources require a new class of use cases
In order to comply to future anticipated regulation and legislation explicit distinction of
Distributed Energy Resources will be required
Distributed Energy Resources represent the current situation
A consistent model requires clear criteria to separate the new DER Domain from the
existing Domains, especially from Bulk Generation and the Customer Domain. Initial criteria
are given in Table 1: Separation criteria for the DER-Domain.
o ―Control‖ The generation units in the Customer Domain can not be remote
controlled by an operator. The generation units in the DER and Bulk Generation
Domain are under control of an operator, (approximately comparably with the
controllability of bulk generation units today).
o ―Connection point‖. The generation units in the bulk generation domain are
predominantly connected to the high voltage level. The generation units in the DER
Domain are predominantly connected to the medium voltage level (in some cases
also to the low voltage level) and the generation units in the customer domain to the
low voltage level.

Table 1: Separation criteria for the DER-Domain

Criteria / Domain Bulk Generation Distributed Energy Resources Consumer

Control Direct direct indirect
Connection Point high voltage medium voltage / low voltage low voltage

One can uniquely model the two extremes as shown in Figure 1 (―Centralized Energy System‖ and
―Decentralized Energy System‖) and the space between them as follows:

―Fully Centralized Energy System‖

At the extreme point of ―Centralized Energy System‖, no distributed energy resources exist
and ―Distributed Energy Resources‖ Domain is not needed.

―Fully Decentralized Energy System‖

At the extreme point of ―Decentralized Energy System‖, no bulk generation systems exist
and the ―Bulk Generation‖ Domain is not needed. The power generation is realized by a
large number of distributed and interconnected power generation units. The generation
power of the distributed generation units are aggregated by the distribution network to the
transmission network. Areas with power reserve can supply areas with power demand. Due
to the constantly changing weather situation over Europe the mix of the regions will
permanently change.

A level of decentralization between both turning points.

This case will correspond to reality, which shows that the trend here is towards an
increasing degree of decentralization. Furthermore, it is assumed that both extreme
positions will not be reached, they are only theoretical. The mixture of ‗bulk generation‘ and
‗distributed energy generation‘ (which includes a significant proportion of volatile energy
generating units) will effect an increase of volatility in the operation of classical generating
units. This is primarily the case in countries, where legislations determine the feed-in of
energy from renewable sources.

20
 Figure 2: EU extension of the NIST Model

Figure 2 also defines the scope of PAN European Energy Exchange System and application
area of a microgrid architecture:

The application area of the hierarchical mesh cell architectures (microgrids) includes the
Customer, Distribution, and Distributed Energy Resources domains. One objective is to
find a balance between production and consumption as locally as possible in order to
avoid transmission losses and increase transmission reliability through ancillary
services such as reserves volt/var support, and frequency support .For other objectives
for microgrids see also use case WGSP-0400 The Pan European Energy Exchange
System (PEEES), which includes technologies in the transport network for low-loss
wide-area power transmission systems (e. g. high-voltage direct current transmission,
HVDC), better realizing the large-scale energy balance between the regions, which is
essential due to the constantly changing weather situation, which has a significant
influence on the power generation capacity of different regions.
In version 3.0 examples of microgrids and a PAN European Energy Exchange System
will be given.

One should not forget that the customer domain in a Smart Grid has the ability to control their
energy consumption within certain limits. In the future, the smart grid will have two adjustment
possibilities: generation and power consumption (load)) and a large number of new degrees of
freedom to control the power balance (frequency stability).

21
6.3.4 The Flexibility Concept
As a result of ongoing work in the M490 Working Groups (SG-CG/RA and SG-CG/SP), the
flexibility concept has been introduced and is discussed. In this model, consumption, production
and storage are grouped together in a flexibility entity (next to the entities Grid, and Markets). It is
believed that this concept creates much more the required flexibility to support future demand
response use cases then the more rigid classification given in table 1. In version 3.0 of this
document the existing conceptual model will be re-represented in a way that it supports the
flexibility concept and also that it enables maximum re-use of results and standards derived from
the existing conceptual model.

Initial ideas on this are given in table 2 below.

Table 2 (for further study)
CM Domains/Flexibility entities Market Grids Flexibility
Markets +
Bulk Generation +
DER +
Customer +
Transmission +
Distribution +
Operations + + +
Service Provider + + +

6.3.5 Conclusion
The EU Conceptual Model corresponds for the most part with the NIST Model and extends it with a
new DER Domain to fulfill the specific European requirements. It is a future-oriented model,
because it allows the description of a totally centralized grid, a totally decentralized grid and a
mixture between both extreme points on a defined level. The application area of the hierarchical
mesh cell architectures will allow in future the description of microgrid architecture and local energy
management systems, that are integrated in the future European Smart Grid system.

6.4 Reference Architecture Viewpoints

The report of the Joint Working Group (JWG) for Standards for the Smart Grids [JWG-SG 2011]
had outlined some of the potential viewpoints that the work of M/490 might have to deal with:
 Conceptual Architecture. A high-level presentation of the major stakeholders or the major
(business) domains in the system and their interactions.
 Functional Architecture. An arrangement of functions and their sub-functions and interfaces
(internal and external) that defines the execution sequencing, the conditions for control or
data flow, and the performance requirements to satisfy the requirements baseline. (IEEE
1220)
 Communication Architecture. A specialization of the former focusing on connectivity.
 Information Security Architecture. A detailed description of all aspects of the system that
relate to information security, along with a set of principles to guide the design. A security
architecture describes how the system is put together to satisfy the security requirements.
 Information Architecture. An abstract but formal representation of entities including their
properties, relationships and the operations that can be performed on them.

As such, these viewpoints could be very much targeting the Information and Communication
Technology (ICT) aspects of the Smart Grid. However, this aspect – though an essential element
of the Smart Grid – cannot be seen in isolation of the other essential aspect of the Smart Grid: the
Power Technology. The choice of the appropriate viewpoints and their level of granularity are
therefore very important. This is addressed by the section below.

22
Considering the JWG recommendations and the requirements defined in section 6.2, the following
viewpoints have been selected as the most appropriate to represent the different aspects of Smart
Grids systems:
 Business Architecture
 Functional Architecture
 Information Architecture
 Communication Architecture

The ‗Information Security Architecture‘ listed in the JWG list above has been handled separately
from the SG-CG/RA work by the SG-CG/SGIS. However, alignment of work of both WGs is
deemed essential. At this stage, first elements of this alignment can be found in 7.2.7.

23
7 The Smart Grid Architecture Model (SGAM) Framework
7.1 Interoperability in the context of the Smart Grid

7.1.1 General
Interoperability is seen as the key enabler of smart grid. Consequently the proposed SGAM
framework needs to inherently address interoperability. For the understanding on interoperability in
the context of smart grid and architectural models, a definition and requirements for achieving
interoperability are given.

7.1.2 Definition
A prominent definition describes interoperability as the ability of two or more devices from the
same vendor, or different vendors, to exchange information and use that information for correct co-
operation [IEC61850-2010].
In other words, two or more systems (devices or components) are interoperable, if the two or more
systems are able to perform cooperatively a specific function by using information which is
exchanged. This concept is illustrated in Figure 3.

System B
System A

Information
Exchange

Function

Figure 3: Definition of interoperability – interoperable systems performing a function

Being formulated in a general way, the definition is valid to the entire smart grid.

7.1.3 Interoperability Categories

The interoperability categories introduced by the GridWise Architecture Council [GWAC2008]
represent a widely accepted methodology to describe requirements to achieve interoperability
between systems or components (Figure 4).

24
 Figure 4: Interoperability Categories defined by GWAC [GWAC2008]

The individual categories are divided among the three drivers ―Technical‖, ―Informational‖ and
―Organizational‖. These interoperability categories underline the definition of interoperability in the
previous section 7.1.2. Hence for the realization of an interoperable function, all categories have to
be covered, by means of standards or specifications.

Figure 5: Interoperability Categories and Cross-Cutting Issues [GWAC2008]

25
Cross-cutting issues are topics which need to be considered and agreed on when achieving
interoperability [GWAC 2008]. These topics may affect several or all categories to some extent.
Typical cross-cutting issues are cyber security, engineering, configuration, energy efficiency,
performance and others.

7.2 SGAM Framework Elements

7.2.1 General
The SGAM framework and its methodology are intended to present the design of smart grid use
cases in an architectural viewpoint allowing it both- specific but also neutral regarding solution and
technology. In accordance to the present scope of the M/490 program, the SGAM framework
allows the validation of smart grid use cases and their support by standards.

The SGAM framework consists of five layers representing business objectives and processes,
functions, information exchange and models, communication protocols and components. These
five layers represent an abstract and condensed version of the interoperability categories
introduced in section 7.1.3. Each layer covers the smart grid plane, which is spanned by electrical
domains and information management zones (section 7.2.3). The intention of this model is to
represent on which zones of information management interactions between domains take place. It
allows the presentation of the current state of implementations in the electrical grid, but furthermore
to depict the evolution to future smart grid scenarios by supporting the principles universality,
localization, consistency, flexibility and interoperability.

7.2.2 SGAM Interoperability Layers

In order to allow a clear presentation and simple handling of the architecture model, the
interoperability categories described in section 7.1.3 are aggregated into five abstract
interoperability layers (refer to Figure 6). However in case of a detailed analysis of interoperability
aspects, the abstraction can be unfolded.

Economic / Regulatory Policy

Business Layer
Business Objectives

Business Procedures Function Layer

System B
System A

Business Context
Information Layer
Semantic Understanding

Syntactic Interoperability
Communication Layer
Network Interoperability

Basic Connectivity Component Layer

Interoperation

Figure 6: Grouping into interoperability layers

26
7.2.2.1 Business Layer
The business layer represents the business view on the information exchange related to smart
grids. SGAM can be used to map regulatory and economic (market) structures and policies,
business models, business portfolios (products & services) of market parties involved. Also
business capabilities and business processes can be represented in this layer. In this way it
supports business executives in decision making related to (new) business models and specific
business projects (business case) as well as regulators in defining new market models. The
Business layer is addressed in more detail in paragraph 8.1.

7.2.2.2 Function Layer

The function layer describes functions and services including their relationships from an
architectural viewpoint. The functions are represented independent from actors and physical
implementations in applications, systems and components. The functions are derived by extracting
the use case functionality which is independent from actors.

7.2.2.3 Information Layer

The information layer describes the information that is being used and exchanged between
functions, services and components. It contains information objects and the underlying canonical
data models. These information objects and canonical data models represent the common
semantics for functions and services in order to allow an interoperable information exchange via
communication means.

7.2.2.4 Communication Layer

The emphasis of the communication layer is to describe protocols and mechanisms for the
interoperable exchange of information between components in the context of the underlying use
case, function or service and related information objects or data models.

7.2.2.5 Component Layer

The emphasis of the component layer is the physical distribution of all participating components in
the smart grid context. This includes system actors, applications, power system equipment
(typically located at process and field level), protection and tele-control devices, network
infrastructure (wired / wireless communication connections, routers, switches, servers) and any
kind of computers.

7.2.3 SGAM - Smart Grid Plane

In general power system management distinguishes between electrical process and information
management viewpoints. These viewpoints can be partitioned into the physical domains of the
electrical energy conversion chain and the hierarchical zones (or levels) for the management of the
electrical process (refer to [IEC62357-2011, IEC 62264-2003]). Applying this concept to the smart
grid conceptual model introduced in section 6.3 allows the foundation of the Smart Grid Plane (see
Figure 7.). This smart grid plane enables the representation on which levels (hierarchical zones) of
power system management interactions between domains take place.

27
 Information
Management

Power System
Market
Equipment &
Energy Conversion Enterprise

Operation

Station
Generation Zones
Transmission Field
Distribution
Process
DER
Domains Customer
Premises

Figure 7: Smart Grid plane - domains and hierarchical zones

According to this concept those domains, which are physically related to the electrical grid (Bulk
Generation, Transmission, Distribution, DER, Customer Premises) are arranged according to the
electrical energy conversion chain. The conceptual domains Operations and Market are part of the
information management and represent specific hierarchical zones. The conceptual domain
Service Provider represents a group of actors which has universal role in the context of smart grid.
This means that a Service Provider can be located at any segment of the smart grid plane
according to the role he has in a specific case.

7.2.4 SGAM Domains

The Smart Grid Plane covers the complete electrical energy conversion chain. This includes the
domains listed in Table 2:

Table 2: SGAM Domains

Domain Description
Bulk Representing generation of electrical energy in bulk quantities, such as by
Generation fossil, nuclear and hydro power plants, off-shore wind farms, large scale solar
power plant (i.e. PV, CSP)– typically connected to the transmission system
Transmission Representing the infrastructure and organization which transports electricity
over long distances

Distribution Representing the infrastructure and organization which distributes electricity to

customers
DER Representing distributed electrical resources directly connected to the public
distribution grid, applying small-scale power generation technologies (typically
in the range of 3 kW to 10.000 kW). These distributed electrical resources may
be directly controlled by DSO
Customer Hosting both - end users of electricity, also producers of electricity. The
Premises premises include industrial, commercial and home facilities (e.g. chemical
plants, airports, harbors, shopping centers, homes). Also generation in form of
e.g. photovoltaic generation, electric vehicles storage, batteries, micro
turbines… are hosted

28
7.2.5 SGAM Zones
The SGAM zones represent the hierarchical levels of power system management [IEC62357-
2011]. These zones reflect a hierarchical model which considers the concept of aggregation and
functional separation in power system management. The basic idea of this hierarchical model is
laid down in the Purdue Reference Model for computer-integrated manufacturing which was
adopted by IEC 62264-1 standard for ―enterprise-control system integration‖ [IEC 62264-2003].
This model was also applied to power system management. This is described in IEC 62357
―Reference architecture for object models services‖ [IEC 62357-2003, IEC 62357-1-2012].

The concept of aggregation considers multiple aspects in power system management:

 Data aggregation – data from the field zone is usually aggregated or concentrated in the
station zone in order to reduce the amount of data to be communicated and processed in
the operation zone
 Spatial aggregation – from distinct location to wider area (e.g. HV/MV power system
equipment is usually arranged in bays, several bays form a substation; multiple DER form a
plant station, DER meters in customer premises are aggregated by concentrators for a
neighborhood)

In addition to aggregation the partitioning in zones follows the concept of functional separation.
Different functions are assigned to specific zones. The reason for this assignment is typically the
specific nature of functions, but also considering user philosophies. Real-time functions are
typically in the field and station zone (metering, protection, phasor-measurement, automation…).
Functions which cover an area, multiple substations or plants, city districts are usually located in
operation zone (e.g. wide area monitoring, generation scheduling, load management, balancing,
area power system supervision and control, meter data management…).
The SGAM zones are described in Table 3.

Table 3: SGAM Zones

Zone Description
Process Including the physical, chemical or spatial transformations of energy (electricity,
solar, heat, water, wind …) and the physical equipment directly involved. (e.g.
generators, transformers, circuit breakers, overhead lines, cables, electrical
loads any kind of sensors and actuators which are part or directly connected to
the process,…).
Field Including equipment to protect, control and monitor the process of the power
system, e.g. protection relays, bay controller, any kind of intelligent electronic
devices which acquire and use process data from the power system.
Station Representing the areal aggregation level for field level, e.g. for data
concentration, functional aggregation, substation automation, local SCADA
systems, plant supervision…
Operation Hosting power system control operation in the respective domain, e.g.
distribution management systems (DMS), energy management systems (EMS)
in generation and transmission systems, microgrid management systems,
virtual power plant management systems (aggregating several DER), electric
vehicle (EV) fleet charging management systems.
Enterprise Includes commercial and organizational processes, services and infrastructures
for enterprises (utilities, service providers, energy traders …), e.g. asset
management, logistics, work force management, staff training, customer
relation management, billing and procurement…
Market Reflecting the market operations possible along the energy conversion chain,
e.g. energy trading, mass market, retail market..

In general organizations can have actors in several domains and zones. In the smart grid plane the
areas of the activity of these actors can be shown. E.g. according to the business area of a

29
transmission utility it is likely that the utility covers all segments of the transmission domain, from
process to market.

A service provider offering weather forecast information for distribution system operators and DER
operators could be located to the market zone interacting with the operation zone in the distribution
and DER domain.

7.2.6 SGAM Framework

The SGAM framework is established by merging the concept of the interoperability layers defined
in section 7.2.2 with the previous introduced smart grid plane. This merge results in a model (see
Figure 8) which spans three dimensions:
 Domain
 Interoperability (Layer)
 Zone

Business Objectives
Polit. / Regulat.. Framework

Business Layer

Function Layer
Outline of Usecase
Functions

Interoperability Information Layer

Data Model
Layers Data Model

Communication Layer
Protocol Market
Protocol
Enterprise

Component Layer Operation

Station
Generation Zones
Transmission Field
Distribution
Process
DER
Domains Customer
Premises

Figure 8: SGAM framework

Consisting of the five interoperability layers the SGAM framework allows the representation of
entities and their relationships in the context of smart grid domains, information management
hierarchies and in consideration of interoperability aspects.

30
7.2.7 Cross-cutting Issues and SGAM

7.2.7.1 Application to SGAM interoperability layers

According to the adopting of the concept of interoperability categories, which was introduced in
section 7.1.3, cross-cutting issues apply in the same manner to the abstract interoperability layers.
Figure 9 shows the relation of cross-cutting issues to the five abstracted interoperability layers.

Business Layer

Cross-Cutting Issues
Function Layer

System B
System A

Information Layer

Communication Layer

Component Layer

Interoperation

Figure 9: Interoperability layers and cross-cutting issues

Figure 10 depicts the impact of crosscutting issues to the individual interoperability layers from the
overall SGAM framework prospective.
Cross-Cutting Issues

Market

Enterprise

Operation

Station
Generation Zones
Transmission Field
Distribution
Process
DER
Domains Customer
Premises

Figure 10: Impact of cross-cutting issues on SGAM interoperability layers

31
7.2.7.2 Example cyber security
Information Security in Smart Grid is an integral part of the Reference Architecture. The
incorporation of the security aspects is the task of the Smart Grid Information Security Work Group
(SG-CG/SGIS) investigating into existing security standards and their feasibility in a smart grid
environment. A commonly agreed view of SG-CG/RA and SG-CG/SGIS is that security is a
consistent process and has to be addressed upfront, both from a functional and non functional
perspective.

The question has been addressed in two angles:

 How to benefit from the SGAM Methodology to address Security Use Cases
 How to represent the Information Security viewpoint within SGAM.

Regarding the first question, the SGAM Methodology based on a Use Case analysis as depicted in
Figure 12 can be directly used for dedicated security functions. Security specific interactions can
be shown on different SGAM layers showing the involved entities, their functional interface in terms
of protocols and information models and also the relating business case. This has been shown on
the example of Role-based Access Control, where SGAM allowed depicting the security specifics
on each layer.

Regarding the representation of security within SGAM, it has been discussed (between SG-CG/RA
and SG-CG/SGIS) to provide a ―security view per layer‖ emphasizing that security is a cross
functional topic, which has to be obeyed in each of the SGAM layers and has been depicted in that
way by the SG-CG/SGIS. This can even more underlined as security is actually to be obeyed per
layer, per domain, and per zone and thus basically per SGAM cell. To allow for the consideration of
security aspects in that detail the SG-CG/SGIS has provided a toolbox, supporting the analysis and
determination of security risks on a per use case base, following the SGAM methodology.

Figure 11: Using the SGIS Toolbox

Moreover, using the toolbox allows identifying available standards, applicable in dedicated use
cases and also to identify gaps, for which further work is has to be done. This approach completes
the SGAM methodology with inherent security considerations.

32
7.3 The SGAM methodology

7.3.1 General
This section introduces the methodology of the SGAM framework. It is intended to provide users
an understanding on its principles and a guideline how to use the SGAM framework.

7.3.2 Principles
The definition of the principles of the SGAM is essential in order to leverage its capabilities for the
universal representation of smart grid architectures. In the following the SGAM principles
universality, localization, consistency, flexibility, scalability, extensibility and interoperability are
described.

7.3.2.1 Universality
The SGAM is intended as a model to represent smart grid architectures in a common and neutral
view. For the M/490 objectives it is essential to provide a solution and technology agnostic model,
which also gives no preferences to existing architectures.

7.3.2.2 Localization
The fundamental idea of the SGAM is to place entities to the appropriate location in the smart grid
plane and layer respectively. With this principle an entity and its relation to other entities can be
clearly represented in a comprehensive and systematic view. E.g. a given smart grid use case can
be described from an architectural viewpoint. This includes its entities (business processes,
functions, information exchange, data objects, protocols, components) in affected and appropriate
domains, zones and layers.

7.3.2.3 Consistency
A consistent mapping of a given use case or function means that all SGAM layers are covered with
an appropriate entity. If a layer remains open, this implies that there is no specification (data
model, protocol) or component available to support the use case or function. This inconsistency
shows that there is the need for specification or standard in order to realize the given use case or
function. When all five layers are consistently covered, the use case or function can be
implemented with the given specifications / standards and components.

7.3.2.4 Flexibility
In order to allow alternative designs and implementations of use cases, functions or services, the
principle of flexibility can be applied to any layer of SGAM. This principle is essential to enable
future mappings as smart grid use cases, functions and services evolve. Furthermore the principle
of flexibility allows to map extensibility, scalability and upgradability of a given smart grid
architecture.

Flexibility includes the following methods:

 Use cases, functions or services are in general independent of the zone. E.g. a centralized
Distribution Management System (DMS) function can be placed in operation zone; a
distributed DMS function can be placed in field zone.
 Functions or services can be nested in different components case by case.
 A given use case, function or service can be mapped to information and communication
layer in many different ways in order to address specific functional and non-functional
requirements. E.g. the information exchange between control centers and substations can
be realized with IEC 61850 over IP networks or with IEC 60870-5-101 over SDH
(Synchronous Digital Hierarchy) communication networks.

33
7.3.2.5 Scalability
The SGAM encompasses the entire smart grid from a top level view. An enlargement to specific
domains and zones is possible in order to detail given use cases, functions and services. E.g. the
SGAM could be scaled and detailed focusing on microgrid scenarios only.

7.3.2.6 Extensibility
The SGAM reflects domains and zones of organizations which are seen from the current state. In
the evolution of the smart grid there might be a need to extend the SGAM by adding new domains
and zones.

7.3.2.7 Interoperability
Picking up the GWAC Stack methodology [GWAC2008], the SGAM represents a kind of a three-
dimensional, abstract aggregation of the GWAC Stack interoperability categories to the smart grid
plane. By doing this, the interaction between actors, applications, systems and components
(component layer) is indicated by their connections or associations via information exchange and
data models (information layer), protocols (communication layer) ,function or service (function
layer) and business constraints (business layer). Generally the connection between entities
(components, protocols, data models) is established by interfaces. In other words the consistency
of an interoperable interaction can be represented by a consistent chain of entities, interfaces and
connections in the SGAM layers.

The principles of Consistency and Interoperability constitute the coherency of the SGAM.
Consistency ensures that the five layers are unambiguously linked; interoperability ensures that the
conditions for interaction (interfaces, specifications, standards) are met within each layer. Both
principles need to be fulfilled for a given use case, function or service to be realized.

7.3.3 Mapping of use cases to SGAM framework

This section describes the basic process to map use cases to the SGAM framework. A detailed
example can be found in annex B.2.4.

The mapping process can be applied to the following tasks, which are considered relevant for the
present mandate M/490:
 Mapping of use cases in order to validate the support by standards
 Identifying gaps in respect to standards
 Mapping of existing architectures into a general view
 Developing smart grid architectures.

On overview of the process and its steps is depicted in Figure 12.

Depending on the task the process can be carried out iteratively.

34
 Use Case SGAM

Control reactive power of DER unit Network Operations

Reporting and Statistics Business Objectives
Audit Polit. / Regulat.. Framework
DMS

Volt/Var
Control
Business Layer
Distribution
SCADA
Stabilize and Optimize

Function Layer

Distribution Outline of Usecase

Data Collector
Functions

Interoperability Information Layer

Data Model
Layers Data Model
Data DER Control
Acquisition Supervision

Distributed
Communication Layer
Protocol Market
Distribution IED Generation
Protocol
Enterprise

Component Layer Operation

Station
Grid
Generation Zones
Transmission Field
Distribution
Process
DER
Domains Customer
Premises

Figure 12: Use case mapping process to SGAM

7.3.3.1 Use Case Analysis

The starting point is an analysis of the use case to be mapped. It needs to be verified that a use
case description provides the sufficient information which is necessary for the mapping. This
information includes:
 Name, scope and objective
 Use case diagram
 Actor names, types
 Preconditions, assumptions, post conditions
 Use case steps
 Information which is exchanged among actors
 Functional and non-functional requirements.

The use case template considered by M/490 Sustainable Process WG provides the required
information.
It is crucial that hard constraints are identified from a use case description. These constraints may
have impact on the sequence of steps carried out for the mapping process.

7.3.3.2 Development of the Component Layer

The content of the component layer is derived from the use case information on actors. As actors
can be of type devices, applications, persons and organizations, these can be associated to
domains relevant for the underlying use case. In the same manner the hierarchical zones can be
identified indicating where individual actors reside.

7.3.3.3 Development of the Business Layer

The business layer is intended to host the business processes, services and organizations which
are linked to the use case to be mapped. This includes also the business objectives, economic and
regulatory constraints underlying to the use case. These business entities are located to the
appropriate domain and zone.

7.3.3.4 Development of the Function Layer

The function layer is intended to represent functions and their interrelations in respect to domains
and zones. Functions are derived from the use case by extracting its functionality. Typically a use
case consists of several sub use cases with specific relationships. These sub use case can be
transformed to functions when formulating them in an abstract and actor independent way.

35
7.3.3.5 Development of the Information Layer
The information layer describes the information that is being used and exchanged between
functions, services and components. The information objects which are exchanged between actors
are derived from the use case description in form of use case steps and sequence diagrams.
Underlying canonical data models are identified by analysis of available standards if these provide
support for the exchanged information objects. Information objects and canonical data models are
located to the appropriate domain and zone being used.

7.3.3.6 Development of the Communication Layer

The emphasis of the communication layer is to describe protocols and mechanisms for the
interoperable exchange of information between the use case actors. Appropriate protocols and
mechanisms are identified on the basis of the information objects and canonical data models and
by consideration of non-functional requirements of the use case. Protocols and mechanisms are
located to the appropriate domain and zone being used.

7.3.4 Mapping the business layer with the lower SGAM layers
This is a crucial phase of the methodology. Some guidelines below can be applied.

7.3.4.1 European market structure alignment

Guideline
Define architectural elements on the business layer in accordance to business roles that are
identifiable within the European electricity market.

Rationale
In order to have business architectures derived from this reference architecture match the situation
in all European countries, the roles used in the business interactions must be defined and agreed
upon, or otherwise the responsibilities carried out by those roles are inconsistent and the
interactions (and consequently the interfaces) between roles are unclear. This results in a system
that is not interoperable.

Currently, the Harmonized Electricity Market Role Model by ENTSO-E, EFET and ebIX [ENTSO-E]
is the best candidate, since it is harmonized and fits on all European electricity markets. Note that
this model only represents the current EU situation, based on the current regulations, and that this
might not fit future developments. Any deviation from this model should be documented and
preferably discussed and agreed upon with the creators of the model and/or regulators (e.g.
through Expert Group 3 of the European Commission's Task Force on Smart Grids).

Approach
Use the HEM-RM of ENTSO-E, EFET and ebIX (freely downloadable from the ebIX website at
http://www.ebix.org/content.aspx?ContentId=1117&SelectedMenu=8) as a guidance to select and
define your business roles and their interactions.

7.3.4.2 Consistency with the business layer

Guideline
Ensure consistent association between roles identified on the business layer and architectural
elements identified on other layers, such as functions, applications, databases, or power system
elements. Make sure there is a 1-to-n mapping from a single role to one or more architectural
elements in the other layers, mitigating ambiguity of responsibilities for architectural elements.

Rationale
when a clear mapping is made between the roles in the business layer and the architectural
elements in the other layers of SGAM (functions, interfaces, information, communication
infrastructure, components …), one automatically knows which role is responsible for an
architectural element and which business interfaces exist between these roles.

36
For example: the functional layer provides a list of functions required for the execution of a
business process in the business layer. Due to the role mapping it is clear which roles are
responsible for a specific function. Consequently none of the functions (and in lower layers
information, interfaces and components) is omitted when realizing the business process and
ownership/responsibility is clear.

Approach
once the architectural elements of the layer under work are defined, one needs to check how these
map to the business roles from the roles defined on the business layer. If one cannot map an
element onto a single role from the role model, the responsibility on that element is unclear and
needs further investigation before continuing.

37
8 Reference Architecture Elements
The Conceptual Model (as defined in 6.3) consists of several domains, each of which contain
applications and actors that are connected by associations through interfaces.

The Conceptual Model can be regarded as the basis from which regulation, business models, ICT
architectures, standards etc. can be derived. Since it forms the common starting point for all these
activities, it has the potential to ensure consistency between all these mentioned perspectives /
viewpoints.

8.1 Business Architecture

It is commonly understood that ICT solutions are meant to support business processes, and that
business processes of an organization produce products or services (in the service industry).
Products and/or services are offered by that organization to its customers (residential of business)
on a market. These markets may be subject to regulation in order to ensure a level playing field.
Some markets/ products /services may even be fully regulated (e.g. unbundling).

Therefore it is essential that in creating ICT standards for inter-operability, the relation to markets,
products and processes as described here, is well understood and aligned. Only then ICT solutions
really support the business. This logic is well presented in the SGAM, showing the business layer
as the top layer of the SGAM frame work.

Although standardization of market models and business models itself is out of scope of M/490,
good interoperability is essential in order to create well-functioning markets. This requires
standardized business services and interfaces, and this is in scope of M/490.

In this paragraph the business architecture is addressed from a methodology point of view, with the
objective to ensure that whatever market or business models are selected, the correct business
services and underlying architectures are developed in a consistent and coherent way. The
business architectures are modeled in the business layer of the SGAM, and comprise the markets
and enterprise zone of the SGAM layer, thereby also coping with regulatory aspects of markets
and business objectives ate enterprise level.

The basis for alignment between organizations, roles & responsibilities, and application &
information architectures, is created by the use of the meta-model, as shown in Figure 13 (source
TOGAF 9.1).

38
 Figure 13: Meta model (TOGAF 9.1)

The use of this model also ensures alignment between the work of the M/490 working groups SG-
CG/SP (Sustainable Processes WG), SG-CG/RA (Reference Architecture WG), and the
development of a generic market model by the EU taskforce smart grids (EG3).

Figure 14 defines the relation between the metamodel and the SGAM framework, and it specifies
more in detail what artifacts/deliverables should come out of the business architecture layer. The
data entity corresponds with the information layer, the application component with the functional
layer, and the technology component and platform services with the communication and
component layer.

Figure 14: Relation Meta-model to SGAM

39
In the business architecture layer, the definition and overview (listing) of the following deliverables
are foreseen:
 Roles & actors
 Business functions (or business function model)
 Business services
 Business processes (or business process model)

8.1.1 Roles & actors

In a market model in the business layer, roles are defined. These roles are mainly defined in terms
of responsibility (ref. ENTSO-E/eBIX, see also Annex H). Then these roles are allocated to market
parties. A party hereby is defined as a legal entity performing one or more roles (ref.[NIST 2009]).

This role-allocation to parties may be subject to regulation / legislation.

A role represents the external intended behavior of a party. A party cannot share a role.
Businesses carry out their activities by performing roles (e.g. System Operator, Trader). Roles
describe external business transaction with other parties in relation to the goal of a given business
transaction.

The concept of an ―Actor‖ is very general and can cover People (their roles or jobs), systems,
databases, organizations, and devices.

Roughly actors, as identified by SG-CG/SP, might be divided into system actors and business
actors (Ref. IEC TC8).
 System actors are covering functions or devices which for example are defined in the
Interface Reference Model (IEC 61968-1). A system actor will perform a task under a
specific role.
 A business actor specifies in fact a « Role » and will correspond 1:1 with roles defined in
the eBIX harmonized role model (possibly some new roles will be required and added to
the eBIX model).

An actor represents a party that participates in a business transaction. Within a given business
transaction an actor assumes a specific role or a set of roles.

For example with respect to unbundling in Europe, the market models define what activities are
regulated and what activities are allowed in the commercial market;
In that respect smart grid parties (DSO, TSO) and smart market parties (suppliers, Energy Service
Companies (ESCOs), traders, customers, etc.) are defined.

The energy transition will require an update of existing market models, which differ today, even in
different EU member states. It is the ambition of the EU to harmonize existing market models and
to develop a generic EU market model.

With respect to mandate M/490, work on the definition of a EU generic market models is out of
scope but work on components which are to be used for defining a market model (roles & business
services) is in scope. Therefore, strong alignment between M/490 (especially SG-CG/SP) and EG3
of the EU Smart Grid Task Force is necessary, to guarantee use of the same definition and
overview (listing) of roles & business services.

Only then EU work on market model development and the M/490 work on standards are in sync.

8.1.2 Business Functions

A business function delivers business capabilities closely aligned to an organization, but not
necessarily governed by the organization (ref. TOGAF 9.1)

40
8.1.3 Business Services
A business service supports a business function through an explicitly defined interface and is
explicitly governed by an organization (ref. TOGAF 9.1).

Actors in the conceptual model are connected by associations. Where these actors are
represented by applications, information is exchanged via application interfaces. Where these
interfaces cross boundaries between market parties, we define the information exchanged as
business services. Through these business services market parties will interact.

The definition of business services via which regulated and unregulated market parties will interact,
will be subject or part of regulation/legislation in order to create a level playing field in the smart
market.

The ‗physical‖ energy product, being an energy ―end user proposition‖ from a commercial market
party or an energy transport product (underlying) from a regulated market party, is defined as a
business product. Associations between business products and business services are foreseen
(e.g. a business transaction service related to EV charging). In order to fully facilitate ―smart
markets‖ by ―smart grids‖, it is expected that business services (interfaces) between regulated and
unregulated environments will be prioritized.

A Smart Market hereby is defined as an unregulated environment where energy products and
energy related services are freely produced, traded, sold and consumed between many market
actors.

A Smart Grid is defined a regulated environment where energy is transported and distributed via
energy networks, and which provides relevant data & functionality to facilitate envisioned market
functioning (e.g. switching customers, providing metering data).

8.1.4 Business Processes

In order to realize business services between markets parties, it is important to have a good insight
in the underlying business processes. Furthermore the business processes drive the requirements
for the functional and information architectures.

Creating a Utility common Business process model, (to be derived via a business function model)
contributes to EU economy of scale with respect to application development and can lead to an
―eco -system‖ of interconnected applications; It contributes to M490 interoperability objectives that
go beyond 2 systems interfacing, leading to the realization of defined and specified use cases.

Today, a generic process model for utilities does not exist (for example, in contrast to the telecom
sector where the eTOM reference model of TMF is internationally widely accepted and used).

Related work, leading a smart grid/ smart market high level process model is considered to be in
scope of M490. Input for this work could come from:
 ENTSO-E/eBIX where processes/interactions between actors are described.
 Cooperation between ENTSO-E/eBIX and IEC related to the HMM and CIM model
 IEC standards (e.g. 61850) in which also processes/functions entities are described
 Work from relevant EU research programs
 The SG-CG/SP on sustainable processes is working on use case and generic use cases.

All these results will be input, next to other contributions and existing material for drafting an initial
business capability and process model. This is for further study, input is welcome.

8.1.5 Methodology/ Process

In order to reach and maintain alignment between market model developments and ICT
architecture & services development, the process that needs to be followed is:

41
 1. The definition of a market model which includes defining and allocating clear roles and
responsibilities to market parties. EG3 defines the roles, building on the existing ENTSO-
E/eBIX Harmonized Role Model. EG3 and maps these roles to all market parties and
DSO‘s. An initial mapping of existing roles is given in annex H. New roles may come out of
analysis of uses cases (SG-CG/SP) as well as market model discussions (EG3)
2. M/490 (SG-CG/SP) derives from the use cases, the actors, and maps these actors onto the
roles used by EG3.
3. M/490 (SG-CG/SP) is identifying the information exchange between actors from the use
cases, and since actors are allocated to roles, this also defines the information exchange
between roles. As roles are also allocated to market parties it consequently also defines the
information exchange between market parties, thereby defining the basis for the standard
business services.
4. From the business services defined, the process model, the information, application,
communication & technical architecture should be derived.

This process is shown in Figure 15.

Figure 15: Alignment process between market model developments and ICT architecture &
services development

It is envisaged that, at the end of 2012, the EU commission in its revision of mandate M490 will
prioritize business services that will be necessary between connected parties (SGCP), market
parties and DSO‘s. So, these business services should be addressed with priority, leading to a first
set of standardized interfaces and business services, also required for implementation of the
flexibility concept.

42
8.2 Functional Architecture

8.2.1 General
A functional architecture is intended to describe the functional elements of a system and their
relationship independent from physical implementation, applied technology or assigned actor. In
the context of Smart Grid a functional architecture consists of functions that enable Smart Grid use
cases. The functional layer of the SGAM model hosts functional architectures of Smart Grids.

This section provides the concept of a meta-model to describe functional architectures and gives
an architectural overview of typical functional groups of Smart Grids.

8.2.2 Functional Architecture Meta-model

8.2.2.1 Concept
The objective of this section is to introduce a meta-model, which describes Smart Grid functions
and their relationship from an architectural viewpoint. The basic concept for the description of
functional architectures for Smart Grid is adopted from the M/441 Smart Metering Reference
Architecture [CEN CLC ETSI TR 50572:2011].

Figure 1Figure 16 shows the meta-model concept for the description of functional architectures for
Smart Grid.
Function Group

Function A

Function B Function C

Figure 16: Functional architecture meta-model

Table 4: Terms of functional architecture meta-model

Term Description
Function Represents a logical entity which performs a dedicated function. Being a logical
entity, a function can be physically implemented in various ways.
Function Is a logical aggregation of one or more functions. A function group may also
Group contain one or more function groups.
interaction An ―interaction‖ of two or more functions is indicated by a connecting line
between these functions. Interaction is realized by information exchange via the
interfaces of functions and communication means..
Functional Identifies the functional elements of a system and relates them to each other.
architecture

Figure 16 shows a function group containing the functions A and B that mutually interact. Function
C interacting with function B, is not contained by any function group.

43
An example for a functional architecture is given for the use case ―control of reactive power in
section B.2.4.

8.2.2.2 Flexibility
Being able to describe functional elements of a system and their relationship independent from
physical implementation, applied technology or assigned actor, allows an abstract and flexible
development and use of functional architectures. In terms of SGAM this means, that functions or
function groups can be assigned and shifted over the segments of the SGAM smart grid plane.

The example in Figure 17 illustrates the flexible assignment of functions to SGAM segments.

Market

CRM CRM
Computer Computer
Audit Audit Enterprise

Volt/Var
Gateway Control DMS Gateway DMS
Computer Computer

SCADA SCADA Operation

HMI HES HMI HES

Station
Distribution Distribution
Data Collector Data Collector

Volt/Var
Control
Field
Data
Distribution DER Distribution DER
DER Control
Data DER Control
IEDAcquisition Controller IED Controller
Acquisition

Grid Grid
G G
Process

HV MV LV HV MV LV

Transmission Distribution DER Transmission Distribution DER

Figure 17: Flexibility for assignment of function “Volt/Var Control” to SGAM segments, case
A - in operation zone, case B - in field zone

In case A, the function ―Volt/Var Control‖ is assigned in the operation zone. This is a typical
functional architecture in centralized DMS systems. In case B, the function is located in the field
zone representing a local or decentralized concept. Both scenarios have specific impact on the
other SGAM layers in terms of information exchange, canonical data models, communication
protocols and component capabilities (see example in section B.2.4).

8.2.3 Smart Grid Functional Architecture

8.2.3.1 General
This section provides an overview on function groups that are derived from the Smart Grid systems
introduced by SGCG/FSS [SG-CG/B]. Moreover these function groups are intended to support the
high-level services, which were addressed in the Smart Grids Task Force EG1 report:

44
  Enabling the network to integrate users with new requirements
 Enhancing efficiency in day-to-day grid operation
 Ensuring network security, system control and quality of supply
 Enabling better planning of future network investment
 Improving market functioning and customer service
 Enabling and encouraging stronger and more direct involvement of consumers in their
energy usage and management

8.2.3.2 Smart Grid Function Groups

The smart grid systems cover all five SGAM interoperability layers. Consequently the systems
have specific content in the functional architecture viewpoint. Figure 18 shows the functional
groups of the Smart Grid systems mapped to the Smart Grid domains and zones.

Market places

Market
Trading

Enterprise
Asset & Maintenance management

Aggregated Prosumer Management

Metering-related
Back Office
Weather Forecast & Observation
Generation Management

EMS SCADA

DMS SCADA & GIS

EMS and VPP

AMI
DER Operation

Operation
WAMS
Substation Automation

Smart Loads
Substation Automation

Feeder Automation

Dist. Power Quality control

Station
FACTS

FACTS

Field
Process

Gene- Customer
ration Transmission Distribution DER premises

Figure 18: Overview on Smart Grid function groups derived from Smart Grid Systems

45
A description and further details on the smart grid systems is given in [SG-CG/B].

From a functional prospective the function groups of the individual systems contain further function
groups or function of smaller granularity. E.g. the function group ―Substation Automation‖ can be
decomposed into the function groups ―protection‖, ―control‖, ―monitoring‖, ―data acquisition‖…
which themselves can be break down in further functions or function groups. The key idea is to
identify basic functions which can be seen as reusable building blocks for complex functions. By
the help of these basic functions different functional layouts can be studied and compared (see
section 8.2.2.2).

8.3 Information Architecture

8.3.1 General
This section of the report focuses of the overview of the most important concepts for the
representation and management of the needed information for the Smart grid elements. An
Information Architecture is an abstract but formal representation of entities including their
properties, relationships and the operations that can be performed on them. Important aspects
which are addressed are data management, integration concepts and the interfaces needed. For
those main aspects, the Smart Grid JWG report has already provided a thorough overview what
has be considered state-of-the-art from the viewpoints of standardization bodies. In order to
distinguish between those three aspects in the SGAM, the integration aspects must be seen as a
link between either two or more layers and between one or more fields at plane level. Data models
are typically focusing on the information layer and can be mapped easily onto the SGAM planes.

The following paragraphs focus on the three very aspects of the information architecture in more
detail. Furthermore the concept of ―logical interfaces‖ is introduced which is dedicated to simplify
the development of interface specifications especially in case of multiple actors with relationships
across domains.

8.3.2 Integration technology

While systems and applications in the past were often operated separately, today business
requires interactions between multiple systems and applications to operate effectively. To do so, a
coupling of former separated and heterogeneous systems is necessary. This requires solutions to
integrate those systems in a way their functionality is still available and can be adapted to changing
need. The establishment of a common information model that is to be used throughout many
applications and systems requires solutions to cope with different data sources from the various
actors.

To allow the recombination of different data sources and the establishment of new interfaces
between those systems, syntactic and semantic interoperability is required. Different than in data
or function integration, the implementation of the original systems is not affected by this enterprise
application integration approach.

Usually, the integration will be realized through integration platforms that allow the implementation
of required interfaces – Middleware is often the layer where this integration effort takes place.
Often times the middleware is message-based, meaning components exchange data defined in
messages which are sent from one component to another. XML is then used for various purposes,
like message description and interchange. By shifting the intelligence to interfaces in conjunction
with intelligent routing, publish/subscribe and event mechanisms, it is possible to define efficient
systems spanning across multiple organizations and actors. In general this approach is labeled as
EAI.

SOA goes one step further with the integration approach as well as with the organizational
embedding, but also share the technological concepts of EAI. A SOA requires specific features
according to the service paradigm from the applications to be coupled in order to allow for

46
successful process integration. The smallest units in SOAs are services that provide a defined set
of functionality, being so fine-grained that they provide units for reuse.

However, what exactly a service is and its level of granularity is in many cases defined different.
The term service is often considered from a certain perspective from a particular stakeholder
group, for instance, regarding the structuring of the business or the IT, as being stated by TOGAF.
Different approaches to describe SOAs and to classify their services are further mentioned in
[Uslar et al 2012].

Services, both business and technical, are self-contained, have a contract assigned that specifies
their functionality and how to access it, and produce predictable results. In contrast to the sizing of
applications and their functionality, services are designed to be used with other services in terms of
composition and orchestration. This level of granularity adds more flexibility to business processes,
as they may defined and executed using the services. Services are characterized by loose
coupling and will usually be provided in specific directories where they can be found by third
parties or process engines. Technical services are mostly realized as Web Services using the WS*
technology stack from W3C. The service localization is then realized with Universal Description,
Discovery and Integration (UDDI) that provides standardized way to locate those services. Besides
the possibility of direct coupling, the usage of a platform providing the required functionality to
orchestrate and compose services is highly important and can be realized in SOA middleware.

The features that middleware for this application area usually offers can for example be data
transformation, connection to data sources, automation technology, logging, reporting as well as
filtering and transformation. Such complex middleware is often named ESB. A platform like this can
serve as a focal point for data, but it can also become a bottleneck for the decentralized arranged
services. Therefore, it is beneficial to have a redundant middleware infrastructure that is scalable.
In case a part of the IT infrastructure is not operated by a company itself but by another provider,
the provided infrastructure becomes more and more abstract and blurred, meaning it appears as to
be surrounded by a cloud.

By turning from a central IT to more decentralized systems in the energy sector, more efforts on
system integration have to be spent. The mentioned integration paradigms are very valuable for
Smart Grids, as they can be applied for the integration of decentralized systems, comprising
producers, storage, consumers and other data sources. Here, the integration paradigms of EAI and
SOA may be used for communication, automation as well as for secondary and primary IT.
Internationally standardized solutions already exist to simplify this, like for instance the IEC 62357
SIA, which can be realized using a SOA, or the IEC 62541 OPC Unified Architecture as a SOA-
based approach for data exchange. Nevertheless, there are still gaps that require harmonization
between semantic and syntactic interfaces.

8.3.3 Data Models

According to literature, a data model in software engineering is an abstract model that documents
and organizes the business data for communication between team members and is used as a plan
for developing applications, specifically how data is stored and accessed. If the abstract level is
higher, usually, business functions implemented and exchanged in processes are represented in a
data model, focusing on the data in terms of payloads between stakeholders being exchanged.

Data modeling and description languages are typical ―system enablers‖ transversal to use cases
and should be seen in priority from a top-down approach. It may conflict with the traditional bottom-
up approaches. However, there are many benefits of proceeding top-down starting with the data
models:
 Avoiding useless translators, which increase the complexity of the deployment of smart
grids, increase its costs, reduce its overall reliability, reduce flexibility in the future and
finally speed down the over all market acceptance.
 Avoid misunderstanding between stakeholders from different domains involved in the
system development, and increase the global reliability and interoperability of the system.

47
  Increase the flexibility of the system.
 Increase the speed of spreading the smart grid, by reducing the amount of engineering time
per additional point of connection of IEDs.
 Providing harmonized data model and description language leads to think ‖transverse‖ to
be efficient, with the constraint not only to define an ―ultimate‖ target but also the migration
path from the existing situation.
 Harmonization between various data models takes place before the actual system
development and might lead to a better seamless integration.

In the utility domain, several data models in context with the different aspects for the corresponding
SGAM plane ―Information layer‖ exist and have been thoroughly documented.

Annex 6.2 of the JWG-SG Report on Smart Grid Standardization provides a thorough overview on
the most important data models which have to be seen in context with the smart grid
standardization. As most reports point out, the CIM (IEC 61968, 61970 and 62325) and the IEC
61850 data model are the most prominent data models [Uslar et al 2012]. Fortunately, there are
strong initiatives started by the SG-CG FSSWG group to harmonize the most important data
models for smart grids. Therefore, we assume for a future version of the SGAM, seamless
integration of data model at the information plane between the domains and zones can be
reached.
This report does not recommend (apart from the obvious standards form the JWG reports) any
data model standards but leaves this for the final report of the first set of standards group which will
cover, based on the SGAM methodology described in this report, individual standards to be
included in the M/490 First list of Standards focusing on meaningful data model standards for the
Smart Grid. Additionally, the identified gaps between those data models are identified and will be
addressed by the final report of the first set of standards group, e.g. IEC 61850 and CIM
harmonization. Additionally, the SGAM method and EA techniques applied like TOGAF and
Archimate provide for a meaningful integration and identification of needed date models in a
context.

8.3.4 Interfaces
Most of the interfaces are normally seen between the domains and zones on the information plane.
However, also interfaces between the planes must exist. Data like measurements and control
signals are to be exchanged between those layers. The SGAM principles were created to make
sure that both data models and interfaces for technical standardization could be mapped and
properly addressed for standards.

As most utility standards were developed with the focus on the separation of concerns, interfaces
are usually specified technology independent (ETSI M2M, IEC 61850 ACSI, CIM profiles (in RDF,
OPC UA) and CIS/IRM) and can therefore be assumed somehow fix for a reference architecture as
the semantics and syntax usually stays stable over the system‘s lifecycle.

The generic basic interfaces can be supplied by literally unlimited numbers of technology
mappings) most of the time, a vast number already exists because of the different use cases the
standards have), however standardization most of the time recommends some of them only.
Choosing the appropriate technology mapping for an interface depends on the functional and non-
functional requirements of a use case and on the given context. This aspect is similar for the
communications architecture plane. The non-functional aspects of an interface and data model are
addressed by the IEC PAS 62559 IntelliGrid template and its extensions by the WG SP of the
mandate. In a Use case, the interfaces and data models which will be mapped onto the SGAM for
structuring can be identified from a pre-filled template and easily be annotated for the later system
development.

The SGAM focuses on the possibility to model different types of uses for interfaces on plane and
layer level, making it easier to distinguish between the interfaces which cover different domains of

48
the conceptual models, different roles (e.g. at market or unbundling level) and of course technical
systems.

8.3.5 Logical interfaces

The concept of logical interfaces is intended to provide a methodology for a systematic
development of interface specifications. The resulting interface specification includes the
information to be exchanged via the interface. This method offers advantages especially when
multiple actors interoperate among different domains. Focusing on logical relationships, this
method is independent from physical implementations of interfaces making it well applicable in
concept studies e.g. in standardization.

Figure 19 illustrates the concept of logical interfaces in the context of SGAM domains and zones.

Market*
Actor A1 Actor A2 Actor B1

Operation*

Station*

Zones
Logical
Interfaces
Field*

Resource B1 Resource

Process

Electrical Grid
(* zones of actors and
Domain A Domain B implementation of
logical interface is
Domains depending on concept)

Figure 19: Concept of logical interfaces in the context of domains and zones

The generic example consists of business actors (A1, A2, B1) and a system actor (resource B1)
assigned to domains A and B. In this example resource B is connected to the electrical grid and
might be assigned to process zone. The business actors can be assigned to any zone, depending
on the type of actor and the specific use case.

All actors may interact with other actors across the domain boundary but also within domains, e.g.
actor A1 interacts with resource B1, actor A2 interacts with actor B2, actor B1 interacts with
resource B1. The logical interfaces, indicated by the dots on the circle line at the domain boundary,
manage the information exchange among all connected actors. For doing this, all actors have to
provide the information in quality and quantity which is expected by the other actors. This idea of
logical information exchange is independent from physical implementation, which can be realized
with computers, dedicated gateways, and interface components (e.g. integrated in resource B1).
This makes this concept flexible providing the necessary interface specifications required for
implementation.

49
For the systematic development of interface specifications the information which is available in use
case descriptions can be used. The necessary steps can be summarized as follows:
 Sorting use cases to logical interfaces
o The use case actors are mapped to the appropriate domains and zones
o The logical interfaces result from crossing through the circle of the connection
between interacting actors
 Identification of exchanged information per logical interface
o The exchanged information is assigned to the respective logical interfaces (dot on
circle line)
o This is done for all use cases
 Merging of interfaces specifications
o The result is a list of information for each logical interface
o Duplicates can be identified and removed

In conclusion this concept can be used for the development of information specifications
 For the analysis if standards are available which provide necessary support by data models
 For the extension of data model standards for new use cases
 Used in R&D and customer projects.

8.4 Communication Architecture

The Communication Architecture document (see Annex F) deals with communication aspects of
the Smart Grid. The main objective of the study on Smart Grid communications is to identify gaps
that need to be addressed in standardization organizations. This work considered generic Smart
Grid use cases to derive the requirements and to consider the adequacy of those requirements to
the existing communications standards in order to identify communication standards gaps. It was
found that there are no specific standardization gaps for Layer 1 to Layer 4 standards (according to
OSI model) mandating the immediate need for evolution of existing standards.

However, there is an immediate need to develop profiling and interoperability specifications based
on the existing communications standards. The profiling work is the task of the SDOs. However, for
the purpose of explaining our vision of such a profiling, a draft profile is proposed as an example of
Smart Grid sub-network architecture.

The first section of the document provides a set of recommendations for standardization work as
well as a mapping of the communication technologies to Smart Grid communication sub-networks
that are listed in the section below.

The remaining part of the document provides:

 An overview of the Communication standards applicable to Smart Grid communications.
 A description of generic Smart Grid use cases, their communication requirements,
along with recommendations on how to setup the communication networks to address
these requirements.
 An example of profile and some interoperability considerations.

8.4.1 Recommendations

8.4.1.1 Recommendation 1
Examining the communication needs of different Smart Grid use cases, it appears that there are
cases that have very stringent communications requirements (PMU, Tele-protection, etc.).
However, all these requirements can be addressed using existing communications standards with
sufficient engineering guidelines (see Recommendation 2). There is already a large set of
communication standards for each network segment identified and no gaps mandating the need for
new communication standards have been identified.

50
8.4.1.2 Recommendation 2
Communication network performance including QoS, reliability, and security must be managed so
as to achieve the smart grid communications requirements. This mandates the need to develop
communication profiles on ―how to use‖ the current communication standards for Smart Grids. IEC
in collaboration with bodies such as IETF, IEEE, ETSI, CEN and CENELEC is the right place to
develop such profiles. A profile is defined as a description of how to use the different options and
capabilities within a set of standards for a particular use.

8.4.1.3 Recommendation 3
There is a need to develop a standardized Service Level Specification (i.e. the technical part of a
Service Level Agreement: availability, resiliency, DoS, etc.) that allows a utility network or
application to rely on predictable network performance when communication is provided by a
shared communication infrastructure.

8.4.1.4 Recommendation 4
Deployment constraints mandate the need for both wireline and wireless communications. Utility
access to wireless network resources is necessary. Where spectrum is allocated for use by utility
networks, this will help progress the Smart Grid deployments ensuring the standard work and
products take into account the allocated spectrum for utilities.

8.4.1.5 Recommendation 5
Given the plethora of L1 and L2 technologies (according to OSI) used in the different
communication standards (as well as the upcoming ones), IP shall be the recommended L3
technology to ensure communications are future proof and avoid the unnecessary need for
interworking gateways in different parts of the Smart Grid communication networks.

8.4.1.6 Recommendation 6
This Communication Architecture document recommends a list of applicable communication
technologies as well as their applicability statement to different sub-networks of the
communications architecture. The choice of a technology for a sub-network is left to
implementations, which need to take into account a variety of deployment constraints.

8.4.1.7 Recommendation 7
Profiles (see Recommendation 2) should be used as a basis for building interoperability test
specifications. When interoperability test specifications / suites exist, those should be leveraged for
building test specifications for the communication profiles.

8.4.1.8 Recommendation 8
ESOs should consider the approval of their specifications applicable to Smart Grid as ENs.

Recognizing the role of consortia in providing & developing specifications for communications and
considering the fact that these consortia adopt an open standards approach (i.e. IEEE, IETF, W3C)
the European Commission should endorse the importance of their specifications in building
communications network, including for Smart Grid. There are globally recognized technologies &
deployments for communications that use a selection of open specifications from ESOs, global
SDOs and these consortia. The endorsement of the specifications into ENs, may not be
reasonable in defined timeframe or achievable.

8.4.2 Smart Grid sub-networks

We are identifying the different networks that play a role in the overall communication architecture
and we are representing their scope using the SGAM model (see Figure 8).

The following networks could be defined, see figure 3-2 below where these terms are used:

51
 • (A) Subscriber Access Network
Network that is not part of the utility infrastructure but involve devices and systems that interact
significantly with the utility such as responsive loads in residences and commercial/industrial
facilities, etc.

• (B) Neighborhood network

Network at the distribution level between distribution substations and end users. It is composed of
any number of purpose-built networks that operate at what is often viewed as the ―last mile‖ or
Neighborhood Network level. These networks may service metering, distribution automation, and
public infrastructure for electric vehicle charging, for example.

• (C) Field Area Network

Network at the distribution level upper tier, which is a multi-services tier that integrates the various
sub layer networks and provides backhaul connectivity in two ways: directly back to control centers
via the WAN (defined below) or directly to primary substations to facilitate substation level
distributed intelligence. It also provides peer-to-peer connectivity or hub and spoke connectivity for
distributed intelligence in the distribution level.

• (D) Low-end intra-substation network

Network inside secondary substations or MV/LV transformer station. It usually connects RTUs,
circuit breakers and different power quality sensors.

• (E) Intra-substation network

Network inside a primary distribution substation or inside a transmission substation. It is involved in
low latency critical functions such as tele-protection. Internally to the substation, the networks may
comprise from one to three buses (system bus, process bus, and multi-services bus).

• (F) Inter substation network –

Network that interconnects substations with each other and with control centers. These networks
are wide area networks and the high end performance requirements for them can be stringent in
terms of latency and burst response. In addition, these networks require very flexible scalability
and due to geographic challenges they can require mixed physical media and multiple aggregation
topologies. System control tier networks provide networking for SCADA, SIPS, event messaging,
and remote asset monitoring telemetry traffic, as well as peer-to-peer connectivity for tele-
protection and substation-level distributed intelligence.

• (G) Intra-Control Centre / Intra-Data Centre network

Networks inside two different types of facilities in the utility: utility data centers and utility control
centers. They are at the same logical tier level, but they are not the same networks, as control
centers have very different requirements for connection to real time systems and for security, as
compared to enterprise data centers, which do not connect to real time systems. Each type
provides connectivity for systems inside the facility and connections to external networks, such as
system control and utility tier networks.

• (H) Enterprise Network

Enterprise or campus network, as well as inter-control center network. Since utilities typically have
multiple control centers and multiple campuses that are widely separated geographically.

• (I) Balancing Network

Network that interconnects generation operators and independent power producers with balancing
authorities, and network which interconnects balancing authorities with each other. In some
emerging cases, balancing authorities may also dispatch retail level distributed energy resources
or responsive load.

• (J) Interchange network

Network that interconnects regional reliability coordinators with operators such as transmission

52
operators and power producers, as well as network that connects wholesale electricity markets to
market operators, providers, retailers, and traders. In some cases, the bulk markets are being
opened up to small consumers, so that they have a retail-like aspect that impacts networking for
the involved entities.

• (K) Trans-Regional / Trans-National network

Network that interconnects synchronous grids for power interchange, as well as emerging national
or even continental scale networks for grid monitoring, inter-tie power flow management, and
national or continental scale renewable energy markets. Such networks are just beginning to be
developed.

• (L) Wide and Metropolitan Area Network1

Network that can use public or private infrastructures. They inter-connect network devices over a
wide area (region or country) and are defined through SLAs (Service Level Agreement).

• (M) Industrial Fieldbus Area Network

Networks that interconnect process control equipment mainly in power generation (bulk or
distributed) in the scope of smart grids.

• (J) Interchange networks

• (K) Trans-regional networks

• (I) Balancing networks

Market
• (H) Enterprise Networks
• (G) Intra-Control center Networks

Enterprise • (L) Wide and Metropolitan

• Area Networks

• (F) Inter-substation Networks

Operation
• (E) Intra-substation Networks

• (D) Low-end intra-substation

Station Networks

• ( C) Field Area Networks

Field

• (B) Neighborhood Networks

Process

• (A) Subscriber Access Network

Customer
Generation Transmission Distribution DER
premise
• (M) Industrial Fieldbus
Networks

Figure 20: Mapping of communication networks on SGAM Communication Layer

Note 1 These areas of responsibility are an example mapping and cannot be normative to all
business models.

1 Several of the shown networks could be based on WAN technologies. However since those networks
A. can be run / managed by different stakeholders,
B. could provide different level of security or different SLAs
they are depicted separately. It should be noted however that this is a logical view and that in practice
multiple logical networks can be implemented using a single WAN technology. Implementation design
choices are beyond the scope of this report

53
Note 2 It is assumed that that sub-networks depicted in the above figure are interconnected
(where needed) to provide end-to-end connectivity to applications they support. VPNs,
Gateways and firewalls could provide means to ensure network security or virtualization.

8.4.3 Applicability statement of the Communication Technologies to the Smart Grid Sub-
networks

The following table provides an applicability statement indicating the standardized communication
technologies to the Smart Grid sub-networks depicted in the previous sub-clause. As per
Recommendation 6, the choice of a technology for a sub-network is left to implementations, which
need to take into account a variety of deployment constraints.

Note This report addresses communication technologies related to smart grid deployment. It
includes communication architecture and protocols that could be used in smart metering
deployments as well as other use cases (like feeder automation, FLISR etc.). For AMI only
specific standards, please refer to CEN/CLC/ETSI TR 50572 and other future deliverables
as listed in SMCG_Sec0025_DC_V0.3 Work Program Document.

54
1
2 Table 5: Applicability statement of the communication technologies to the smart grid sub-networks

e ss

e
wo a cc

ntr

us
re
n

n
ork ood

l ce

ld b
ti o

tio

ent
net riber

al

nal
sta tr a

n
rk

ge
sta

sta

Fie
tro
h

ac

gio

atio
sub nd i n
Ne bour

rise
sc

rea

han
tio

sub
sub

on

dat

cin

l
s re

tria
Sub

sn
erp
ld a

ra c
-e
igh

erc
an
ra-

er-
tw

us
ra

n
Low

WA
Tr a

Tr a
Ent

Bal
Ne

Fie

Ind
I nt

I nt

I nt

I nt
int
A B C D E F G H I J K L M
Narrow band
PLC (Medium
and Low
voltage) x x x
Narrow band
PLC (High and
very High
voltage) x x
Broadband PLC x x
IEEE 802.15.4 x x x
IEEE 802.11 x x x x
IEEE 802.3/1 x x x x x x
IEEE 802.16 x x x
ETSI TS 102 887 x x
IPv4 x x x x x x x x x x x x x x
IPv6 x x x x x x x x x x x x x x
RPL / 6LowPan x x x
IEC 61850 x x x x x x
IEC 60870-5 x x x x
GSM / GPRS /
EDGE x x x
3G / WCDMA /
UMTS / HSPA x x x x x x x x x x
LTE/LTE-A x x x x x x x x x x x x x
SDH/OTN x x x x x x x x x x x x x x
IP MPLS / MPLS
TP x x x x x x x x x x x x x x
EN 13757 x
3 DSL/PON x x x x 2

2 IEEE GEPON and EPON are considered to be part of DSL/PON line

55
 Annex A
Background Architecture Work
4 A.1 Objectives of this annex
5 This annex is dealing with the main principles for architecture management which have been
6 applied developing both the SGAM and the Reference Architecture.
7
8 A.1.1 Aspects of a Common View: evolvability, simplicity and reuse of
9 building blocks
10 For the understanding of the term Reference Architecture in the context of this document, various
11 definitions have to be taken into account. Different relevant terms and definitions exist for
12 architectures. The paragraphs provides and overview on how the term is used in context of this
13 document and the ISO 42010.
14
15 One relevant ISO/IEC definition can be found in the ISO/IEC FDIS 42010 (2011): ―Systems and
16 software engineering — Architecture description‖
17
18 Architecture
19 Fundamental concepts or properties of a system in its environment embodied in its
20 elements, relationships, and in the principles of its design and evolution.
21
22 Architecting
23 Process of conceiving, defining, expressing, documenting, communicating, certifying proper
24 implementation of, maintaining and improving an architecture throughout a system‘s life
25 cycle.
26
27 Architecture Framework
28 Conventions, principles and practices for the description of architectures established within
29 a specific domain of application and/or community of stakeholders.
30
31 Reference Architecture
32 A Reference Architecture describes the structure of a system with its element types and
33 their structures, as well as their interaction types, among each other and with their
34 environment. Describing this, a Reference Architecture defines restrictions for an
35 instantiation (concrete architecture). Through abstraction from individual details, a
36 Reference Architecture is universally valid within a specific domain. Further architectures
37 with the same functional requirements can be constructed based on the reference
38 architecture. Along with reference architectures comes a recommendation, based on
39 experiences from existing developments as well as from a wide acceptance and recognition
40 by its users or per definition.
41

56
 Architecture
Description

42
43 Figure 21: Metamodel of ISO/IEC 42010

44 What characterizes a Reference Architecture can be seen in the following list and overview of
45 typical attributes which are covered by it:
46  Recommendation character
47  Declared by author
48  Acceptance and recognition by users
49  Generality
50  Abstracts from specific characteristics
51  Universal validity just possible within a specific domain or in relation to a set of use cases
52
53 In general, an architecture description is a work product used to express an architecture (of a
54 system). Its content varies depending on the architecture. Stakeholders and their concerns and the
55 Architecture Description usually depict the relevant stakeholders concerns.
56
57 Different Architecture Views are used to express architecture and to cover the stakeholder's
58 concerns. Architecture Viewpoints are used to describe (relevant) architecture views; those
59 Viewpoints describe stakeholders, concerns, notations, etc.
60
61 A.1.2 Clarification of views: power vs. communication; applications vs.
62 services
63 When developing a Reference Architecture, it is important to know which aspects and view-points
64 should be addressed in order to keep the model as simple as possible and not to introduce to
65 much un-needed complexity. Often, those viewpoints differ in granularity, depending on the
66 covered concerns. Typical possible viewpoints are:

57
67
68  Enterprise viewpoint,
69  Information viewpoint,
70  Computational viewpoint,
71  Engineering viewpoint,
72  Technology Viewpoint (RM-ODP, ISO/IEC 10746)
73  Business Architecture viewpoint,
74  Application Architecture viewpoint,
75  Data Architecture viewpoint,
76  Technology Architecture viewpoint
77
78 With regard to methodologies like The Open Group Architecture Framework (TOGAF) or Zachman
79 some of those viewpoints should always be addressed in context because they are inseparable. As
80 for the SGAM, section 7 of this document will show the addressed viewpoints at zones, planes and
81 layers.

82 A.2 Relationship to existing Architectures

83 As this is not the first architecture to be developed, most SDOs and their TCs already have created
84 certain reference models and different viewpoints which are already used all around the world. As
85 the overall project time to create the RA for the M490 process was limited, existing work was taken
86 into account. The following (non-exhaustive) list contains already existing work whose principles
87 and ideas were used by the RWAG:
88
89  IEC SIA (TC 57 and SMB SG 3)
90  GridWise
91  Intelligrid Framework
92  NIST Conceptual Model
93  eTom/SID/Frameworx
94  Electrinet
95  OASIS, ebIX, ENTSO-E
96  SG-CG First Set of Standards and Security Work Groups key issues
97
98 As for the SGAM, section 7 of this document outlines which aspects of those models were
99 incorporated into the SGAM and which were not. Annex B of this document provides conceptual
100 mappings to the SGAM layers for several of the aforementioned frameworks, making an alignment
101 of SGAM use cases with those models possible.

102 A.3 Overview of one possible RA lifecycle-model

103 The possible lifecycle for the creation and maintenance of a reference architecture depicted in
104 Figure 22 can be easily adopted by M/490 processes.
105

58
106
107 Figure 22: General Lifecycle for a reference architecture model

108 Firstly, the existing systems and architecture, principles and concepts of a domain, some relevant
109 elements, relations and patterns are extracted, This step was performed by the SG-CG/RA
110 members, taking into account exiting work and EGx and JWG reports. A first version of the
111 reference architecture, the SGAM has been developed. However, as it is applied in practice,
112 special requirements which are not covered by the general model can occur and must be
113 instantiated. They must be incorporated in the architecture development and will be fulfilled by the
114 systems which are instance-based on the reference architecture form the domain. Again, the
115 knowledge gathered about the domain and application of the reference architecture is brought
116 back in the process to build a new version of the reference architecture. It is strongly suggested to
117 use this model when first experiences with the SGAM in practice are gained to create a new
118 version 2.0 of the SGAM.
119

59
 Annex B
Model mappings
120 B.1 Conceptual Model
121 This section will be completed in a subsequent version.

122 B.2 SGAM Framework

123 B.2.1 Quality of interoperability

124 The quality of interoperability can be measured by integration effort. When systems are to be
125 integrated to fulfill a function cooperatively, all interoperability categories need to be covered. Here
126 standards help to increase the quality of interoperability by reducing the integration effort.
127
128 Figure 23 shows the relationship between integration efforts and system complexity in respect to
129 the use of standards. A standard is designated
130  ―rich‖, when the standard covers several interoperability categories (e.g. IEC 61850,
131 covering the categories from basic connectivity up to semantic understanding, even
132 including aspects of business context)
133  ―simple‖, when the standard covers a single or few interoperability categories (e.g.
134 Ethernet, covering aspects of basic connectivity, syntactic and network interoperability)
135
Quality of
Integration
Interoperability
Efforts
Low
No standard
Medium
Simple standard

High
Rich standard

System
Complexity
136
137 Figure 23: Quality of interoperability

138 Generally the integration effort to achieve full interoperability increases by system complexity.
139 Having rich standards available (for a given integration task), which provide specifications for the
140 required interoperability categories (e.g. standardized connectors, communication protocols,
141 semantic data models, standardized functions), will ease the integration work. Having simple or
142 even no standards applicable for the integration task may result in higher efforts due to project
143 specific adaptions.

60
144
145 Consequently ―rich‖ standards bridging as many interoperability categories as possible are to be
146 preferred for smart grid interoperability.
147
148 B.2.2 Specific qualities of interoperability: “Plug-and-play” and
149 “Interchangeability”
150 In the discussion about the meaning of interoperability, the terms ―plug-and-play‖ and
151 ―exchangeability‖ are quite common. Rather than synonyms for interoperability, these terms
152 represent a specific quality of interoperability.
153
154 Plug-and-play
155 Plug-and-play can be described as the ability to add a new component to a system and have it
156 work automatically without having to do any technical analysis or manual configuration. In other
157 words this includes the automatic configuration of specific settings necessary for the integration for
158 systems. In respect to the interoperability categories, the concept of automatic configuration
159 complements standards and specifications with mechanisms and procedures to simplify system
160 integration. At best these mechanisms and procedures are standardized.
161
162 Interchangeability
163 Interchangeability is defined as ―the ability to replace a device supplied by one manufacturer with a
164 device supplied by another manufacturer, without making changes to the other elements in the
165 system” [IEC61850-2010]. This means that interchangeability represents ―hot plug‖ capability of a
166 system or component. For this purpose the system requires a well-defined behavior in respect of
167 function and information exchange, in other words the full specification of all interoperability
168 categories. This full specification can be achieved by using standard profiles (see 2.2.6).
169
170 For a given system or component, the Plug-and-play (auto configuration) capability is not
171 necessary for the support of interchangeability, since pre-configuration is sufficient.
172
173 B.2.3 Standard profiles – a measure to increase the quality of
174 interoperability
175 Generally a profile defines a subset of an entity (e.g. standard or specification). Profiles can be
176 used to reduce the complexity of a given integration task by selecting or restricting standards to the
177 essentially required content. A standard profile may contain a selection of data models,
178 communication services applicable for a specific use case. Furthermore a profile may define
179 instances (e.g. specific device types) and procedures (e.g. programmable logics, message
180 sequences) in order to support interchangeability.
181
182 B.2.4 SGAM Mapping Example
183 The following example illustrates how a use case can is mapped to the SGAM framework. For this
184 example the process which is described in section 7.3.3 is applied. The sample use case ―Control
185 reactive power of DER unit” is a typical use case, which falls under the area of the distribution
186 management.
187
188 This example also illustrates that a use case can be represented with existing devices,
189 infrastructures, functions, communication and information standards and business objective and
190 constraints. Consistency of the layers in respect to the use case is provided by standards, which
191 are applicable for the implementation of the use case.

192 B.2.4.1 Use Case Analysis

193 Starting point is an analysis of the use case to be mapped. It needs to be verified that a use case
194 description provides the sufficient information which is necessary for the mapping.

61
195
196 For this mapping example the required information is taken from
197  Name, scope and objective (Table 6)
198  Use case diagram (Figure 24)
199  Actor names, types (Table 7)
200  Preconditions, assumptions, post conditions (Table 8)
201  Use case steps (Table 9)
202  Information which is exchanged among actors (Table 10)
203
204 The underlying business objective of the use case is the operation of the distribution system in
205 order to deliver electrical energy to customers under consideration of specific constraints. These
206 constraints are typically economic and regulatory oriented, such as e.g. grid codes (incl. technical
207 and non-technical requirements), security of supply, system stability, quality standards, company
208 processes, etc.
209 Table 6: Scope and Objective

Scope and Objectives of Use Case

Related business case Operation of distribution grid
Scope Monitor voltage level in distribution grid, control reactive power of DER unit, volt/var control of
distribution grid,
Objective Monitor and control voltage level of distribution grid in tolerated limits
210

Control reactive power of DER unit Network Operations

Reporting and Statistics
Audit
DMS

Volt/Var
Control

Distribution
SCADA
Stabilize and Optimize

Distribution
Data Collector

Data
DER Control
Acquisition

Distributed
Distribution IED Generation

Grid
211
212 Figure 24: Use Case Diagram for “Control reactive power of DER unit”

213
62
214 Table 7: Actor List “Control reactive power of DER unit”

Actors
Grouping (Community) Group Description

Actor Name Actor Type Actor Description Further information

see Actor List see Actor List see Actor List specific to this Use
Case
Grid System Power Distribution system
Distribution-IED Device Intelligent Electric Device (IED) is a
communications-enabled controller to
monitor and control automated devices in
distribution which communicates with
Distribution SCADA or other
monitoring/control applications, as well as
distributed capabilities for automatic
operations in a localized area based on
local information and on data exchange
between members of the group.
Operations such as such as tripping circuit
breakers if they sense voltage, current, or
frequency anomalies.
Distributed Generation Device Distributed Generation, also called
Distributed Energy Resources (DER),
includes small-scale generation or storage
of whatever form. This is in contrast to
centralized or bulk generation and/or
storage of electricity. These generation
facilities are part of Demand/Reponse
programs and may be dispatchable
resources. The primary distictions between
Distributed Generation (DG) and Bulk
Generation is: Bulk Generation is attached
via Transmission facilities, output is sold in
wholesale markets, provides base load;
DG is sited on a Customer permises
attached to the Distribution grid, output is
Retail (unless sold via an aggregator), can
provide ancillary services. These
generation facilities include but are not
limited to Photvoltaic panel (PV), micro-
hydro, mindmill, Plug-in Hybrid/Electric
Cars (PHEV), and potentially Fuel cells.
These facilites are usually not scheduled
but can be dispatched.
Distribution Data Device A data concentrator bringing data from
Collector multiple sources and putting it into different
form factors.
Distribution Stabilize and Application Performed by actors to ensure the network
Optimize is operating within appropriate tolerances
across the system. They gather
information for control decisions that
ensure reliable, proper operations
(stability) and more efficient operations
(optimization). Measurement and control
form a feedback loop that allows grid
operators to stabilize the flow of energy
across the electric network or safely
increase the load on a transmission path.
Distribution Management Application A suite of application software that

63
 System monitors and controls the distribution
system equipment based on computer-
aided applications, market information, and
operator control decisions.
Network Operations Application Operational Statistics and Reporting actors
Reporting and Statistics archive on-line data and to perform
feedback analysis about system efficiency
and reliability.
215
216 Table 8: Preconditions, Assumptions, Post condition “Control reactive power of DER unit”

Use Case Conditions

Actor/System/Information/C Triggering Event Pre-conditions Assumption
ontract
• The Grid is continuously monitored
• The Grid topology is known and
reflects the real topology
Distribution Management
• The Grid energy path is known and
System
reflects the real path (effective status of
remote monitored and controllable
switches)
Distribution-IED The device is up and running
The DER is connected to the grid and
Distributed Generation
injects active and reactive power
Distribution Data Collector The device is up and running
Distribution Stabilize and The application is up and running
Optimize
Distribution Management The application is up and running
System
Network Operations The application is up and running
Reporting and Statistics
217
218 Table 9: Step by Step Analysis of Use Case “Control reactive power of DER unit”

Scenario Conditions
No. Scenario Name Primary Actor Triggering Event Pre-Condition Post-Condition
4.1 Data Acquisition Distribution IED Periodically
4.2 SCADA DMS Periodically
4.3 Voltage/Var Distribution Voltage
Control Stabilize and Measurement
Optimize exceeded threshold
4.4 DER Control DMS Control value,
equipment id,
received
4.5 Audit DMS Control action
219
220

64
221 Table 10: Use Case Steps “Control reactive power of DER unit”

Step Triggering Actor Description of the activity Information Information Information Additional Notes
# Event What actor, either Describe the actions that take place in this step producer Receiver exchanged Elaborate on any additional description or value of the step to help support the
primary or secondary including the information to be exchanged. The step descriptions. Short notes on architecture challenges, etc. may also be noted in
is responsible for the should be described in active, present tense this column
activity in this step?
Data Acquisition‖
1a Periodically Distribution Distribution IED acquires analogue Grid Distribution Analogue
IED voltage measurement IED Voltage
Measuremen
t
2 Periodically Distribution Distribution IED transmits voltage Distribution Distribution Voltage
IED measurement IED Data Measuremen
Collector t
3 Periodically Distribution Distribution Data Collector transmits Distribution DMS Voltage
Data Collector voltage measurement to DMS Data Collector Measuremen
system. t
Scada
4 Periodically DMS The DMS System collects data from DMS Network Voltage
the grid, reformates the data and Operations Measuremen
complements it with additional Reporting & t, location,
relevant information , distributes the Statistics, topology
data to DMS applications Distribution information
Stabilize and
Optimize
Voltage/Var Control
5 Voltage Distribution Distribution Stabilize and Optimize Distribution Distribution Violation
Measuremen Stabilize and application detects a threshold Stabilize and Stabilize and information
t exceeded Optimize violation of voltage Optimize Optimize
threshold
6 Threshold Distribution Distribution Stabilize and Optimize Distribution Distribution Start of
Violation Stabilize and application starts Voltage/Var Stabilize and Stabilize and voltage/Var
Optimize calculation Optimize Optimize calculation
7 Start voltage Distribution Distribution Stabilize and Optimize Distribution DMS Control
Var Stabilize and application calculates control value Stabilize and value,
calculation Optimize and identifies equipment to be Optimize equipment id
controlled and transmits value to
DMS

65
 Step Triggering Actor Description of the activity Information Information Information Additional Notes
# Event What actor, either Describe the actions that take place in this step producer Receiver exchanged Elaborate on any additional description or value of the step to help support the
primary or secondary including the information to be exchanged. The step descriptions. Short notes on architecture challenges, etc. may also be noted in
is responsible for the should be described in active, present tense this column
activity in this step?

DER Control
8 Control DMS DMS reformats control value and DMS Distribution Controllable
value, equipment id and transmits Data setpoint
equipment id, controllable setpoint to Distribution Collector
received Data Collector
9 Controllable Distribution Distribution Data Collector device Distribution Distributed Controllable
setpoint Data Collector forwards information to Distributed Data Collector Generation setpoint
received Generation device
10 Controllable Distributed Distributed Generation device Distributed Distributed Operation
setpoint Generation updates its operation parameters Generation Generation parameter
received according to setpoint
11 Operation Distributed Distributed Generation device Distributed Distribution Acknowledg
parameter Generation verifies updated operation mode and Generation Data e information
update acknowledges parameter change Collector
12 Acknowledge Distribution Distribution Data Collector device Distribution DMS Acknowledg
information Data Collector forwards information to DMS Data Collector e information
received
Audit
13 Control DMS DMS application posts control action DMS Network Control
action to Network Operations Reporting & Operations action
Statistics application Reporting &
Statistics
14 Control Network Network Operations Reporting & Network Network Control
action Operations Statistics application documents Operations Operations action
Reporting & control action Reporting & Reporting &
Statistics Statistics Statistics
222

66
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

223 B.2.4.2 Development of the Component Layer

224 The content of the component layer is derived from the use case information on actors. In this
225 example the actors are of type devices, applications and system. These actors are located to the
226 appropriate domain and zone (Figure 25).
227

Enterprise

Audit

Network Operations
Volt/Var Reporting and Statistics
Control Operation

DMS SCADA
Distribution
Stabilize and Optimize

Station

Distribution
Data Collector
Data Field
Acquisition DER Control

Distribution IED Distributed

Generation
Process

Grid
Distribution DER
228
229 Figure 25: Actors and sub use cases mapped to domains and zones, “Control reactive
230 power of DER unit”

231 The actors ―DMS‖, ―Network Operations, Reporting and Statistics‖ and ―Distribution Stabilize and
232 Optimize‖ typically reside in the distribution domain. DMS and Distribution Stabilize and Optimize‖
233 are on operation zone, whereas ―Network Operations, Reporting and Statistics‖ can be in
234 enterprise zone. ―Distribution Data Collector‖ is depicted in distribution domain and station zone,
235 ‖Distribution IED‖ in distribution domain and field zone. ―Distributed Generation‖ is consequently
236 located at DER domain and Field zone. The actor ―Grid‖ is valid in both distribution and DER
237 domain in the process zone.
238
239 In the next step, the mapped use case diagram is transformed to a technical configuration
240 representation by using typical technical symbols (Figure 26)

67
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

241

Market

CRM
Computer
Enterprise

Gateway DMS
Computer

Operation
HMI HES

Station
Distribution
Data Collector

Field
Distribution DER
IED Controller

Grid
G
Process

HV MV LV

Generation Transmission Distribution DER Customer Premise

242
243 Figure 26: Component Layer “Control reactive power of DER unit”

244 The component layer (Figure 26) depicts the use case actors in form of hardware which is used to
245 provide the intended use case functionality. In this example these are computers in the enterprise
246 and operation zones which host the application type actors, dedicated automation devices in field
247 and station zones, and nevertheless the grid is depicted with power system equipment (lines, bus
248 bars, transformers, generators …). To complete this view the typical communication infrastructure
249 is added. This configuration is a sample application, thus various scenarios are possible

250 B.2.4.3 Development of the Business Layer

251 The business layer is intended to host the business processes, services and organizations which
252 are linked to the use case to be mapped. This includes also the business objectives, economic and
253 regulatory constraints underlying to the use case. These business entities are located to the
254 appropriate domain and zone.
255

68
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Market

CRM
Computer
Enterprise

Gateway DMS
Computer

Operation
HMI HES
ve s
o b jecti es
n e ss e ss
Busi ess proc ulatory
n eg
Busi ic and r
om ints Station
Econ constra
Distribution
Data Collector

Field
Distribution DER
IED Controller

Grid
G
Process

HV MV LV

Generation Transmission Distribution DER Customer Premise

256
257 Figure 27: Business Layer “Control reactive power of DER unit”

258
259 The business layer (Figure 27) shows the area which is affected by the use case and consequently
260 influenced by underlying business objectives and economic and regulatory constraints. This means
261 that this objectives and constraints need to be taken into account as non-functional requirements
262 for implementations.

263 B.2.4.4 Development of the Function Layer

264 The function layer is intended to represent functions and their interrelations in respect to domains
265 and zones. Functions are derived from the use case by extracting its functionality. In this example
266 the step-by-step analysis provides the functions of the uses case (Figure 28). The interrelation
267 between functions is implicitly derived from the exchanged information documented in the use case
268 steps (Table 10).
269

69
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Market

CRM
Computer
Audit Enterprise

Volt/Var
Gateway Control DMS
Computer

SCADA Operation
HMI HES

Station
Distribution
Data Collector

Field
Data
Distribution DER
IEDAcquisition DER Control
Controller

Grid
G
Process

HV MV LV

Generation Transmission Distribution DER Customer Premise

270
271 Figure 28: Function Layer “Control reactive power of DER unit”

272 The functions ―Volt/Var Control‖ and ―SCADA‖ typically reside in Distribution/Operation. The
273 function ―Audit‖ is located in Distribution/Enterprise. The functions ―Data Acquisition‖ and ―DER
274 Control‖ are located to Distribution/Field and DER/Field, respectively.

275 B.2.4.5 Development of the Information Layer

276 The information layer describes the information that is being used and exchanged between
277 functions, services and components. The information objects which are exchanged between actors
278 are derived from the use case step description (Table 10). Figure 29 shows the result of the
279 mapping of the exchanged information to the components that represent the use case actors.
280

70
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Market

CRM
Computer
Enterprise
Action Acknow
Audit -ledge
Gateway DMS
Computer
Voltage
Reactive Power Operation
Measurement
HMI HES Setpoint

Reactive Power Station

Distribution Setpoint
Data Collector

Voltage
Measurement Acknow
-ledge DER
Field
Distribution
IED Controller

Grid
G
Process

HV MV LV

Generation Transmission Distribution DER Customer Premise

281
282 Figure 29: Information Layer / Business Context view, “Control reactive power of DER unit”

283 The Canonical Data Model view (Figure 30) of the information layer is intended to show underlying
284 canonical data model standards which are able to provide information objects. In other words for
285 the implementation of the present use case, instances of data objects according to the standards
286 are required. In the present example CIM standard (IEC 61968-4) is an appropriate basis for
287 exchanging information objects in the enterprise and operation zones. From field to operation
288 zone, data objects according IEC 61850-7-4 (Compatible logical node classes and data object
289 classes) and IEC 61850-7-420 (Distributed energy resources logical nodes) are applied.
290

71
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Market

CRM
Computer
Enterprise

Gateway CIM DMS

IEC 61968-4
Computer

Operation
HMI HES

420
IEC 61850-7-4

Station
850-7-
Distribution
Data Collector
IEC 61

Field
Distribution DER
IED Controller

Grid
G
Process

HV MV LV

Generation Transmission Distribution DER Customer Premise

291
292 Figure 30: Information Layer / Canonical Data Model view, “Control reactive power of DER
293 unit”

294 B.2.4.6 Development of the Communication Layer

295 The emphasis of the communication layer is to describe protocols and mechanisms for the
296 interoperable exchange of information between the use case actors. Appropriate protocols and
297 mechanisms are identified on the basis of the information objects and canonical data models and
298 by consideration of non-functional requirements of the use case. The communication layer (Figure
299 31) presents the communication protocols for the data exchange of the necessary information
300 between the components
301

72
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Market

CRM
Computer
Enterprise
IEC 61968-100

Gateway DMS
Computer

IEC 61968-100 Operation

HMI HES

IEC 61850-8-1
ADSL Station
Distribution IEC 61850-8-1
Data Collector GPRS

IEC 61850-8-1
IEEE 1901.1 Field
Distribution DER
IED Controller

Grid
G
Process

HV MV LV

Generation Transmission Distribution DER Customer Premise

302
303 Figure 31: Communication Layer “Control reactive power of DER unit”

304
305 In the enterprise and operation zone IEC 61980-100 is an option for the exchange of CIM data
306 objects. In the field to operation zones there are options of communication standards. IEC 61850 is
307 the state-of-the-art communication protocol in power system automation. This standard can be
308 mapped to different lower layers, such as Ethernet, PLC or wireless communications.
309
310 B.2.5 Relation of SGAM framework to Architecture Standards
311 The SGAM framework has been developed with the focus on supporting the very needs of
312 standardization experts and architects in the utility domain. The focus grew originally out of the
313 need of the conceptual model described in section 6 of this document to be put in context with the
314 very existing smart grid architectures from the view of standardization.
315
316 Section B.2.6 ―Examples and Mappings of existing solutions‖ provides the most relevant examples
317 of how the existing meta-models on reference frameworks to been seen in context with smart grid
318 standardization can be mapped onto the SGAM model itself. However, this section focuses on the
319 need form the domain perspective developed in Utilities by engineers for primary technology,

73
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

320 communication technology and standardization engineers. Another possible view towards the
321 smart grid architecture can be given from the point of a non-domain oriented software engineer.
322
323 In the very context of documenting software architectures, different standards or methodologies
324 have evolved. One of the most prominent standards is the ISO/IEC 42010: Systems Engineering –
325 Architecture description. It focuses on the tool-independent way of conceptualizing architectures
326 for systems, which may be hybrid (e.g. hardware, communications and software). The scope is
327 further detailed as followed [ISO/IEC 42010].
328
329 The complexity of systems has grown to an unprecedented level. This has led to new
330 opportunities, but also to increased challenges for the organizations that create and utilize
331 systems. Concepts, principles and procedures of architecting are increasingly applied to help
332 manage the complexity faced by stakeholders of systems.
333
334 Conceptualization of a system‘s architecture, as expressed in an architecture description, assists
335 the understanding of the system‘s essence and key properties pertaining to its behavior,
336 composition and evolution, which in turn affect concerns such as the feasibility, utility and
337 maintainability of the system.
338
339 Architecture descriptions are used by the parties that create, utilize and manage modern systems
340 to improve communication and co-operation; enabling them to work in an integrated, coherent
341 fashion. Architecture frameworks and architecture description languages are being created as
342 assets that codify the conventions and common practices of architecting and the description of
343 architectures within different communities and domains of application.
344
345 The ISO/IEC 42010 addresses the creation, analysis and sustainment of architectures of systems
346 through the use of architecture descriptions. It provides a core ontology for the description of
347 architectures. The provisions of this International Standard serve to enforce desired properties of
348 architecture descriptions, also specifying provisions that enforce desired properties of architecture
349 frameworks and architecture description languages (ADLs), in order to usefully support the
350 development and use of architecture descriptions. ISO/IEC 42010 provides a basis on which to
351 compare and integrate architecture frameworks and ADLs by providing a common ontology for
352 specifying their contents and can be used to establish a coherent practice for developing
353 architecture descriptions, architecture frameworks and architecture description languages within
354 the context of a life cycle and its processes (which have to be defined outside the standard). This
355 International Standard can further be used to assess conformance of an architecture description, of
356 an architecture framework, of an architecture description language, or of an architecture viewpoint
357 to its provisions.
358
359 One particular way of implementing the ISO/IEC 42010 based ideas proven in industry, addressing
360 the aspect of operationalizing the ideas from the meta-model [Jonkers 2010] are the standards
361 from the Open Group TOGAF and Archimate.
362
363 A major strength of the TOGAF method is its ability to stress the importance of stakeholder
364 concerns for each enterprise architecture development phase: creation, change, and governance.
365 This ability may suggest that TOGAF also describes how an architect should address these
366 concerns. This, however, is not the case. What TOGAF actually offers is a sort of ―open interface‖
367 for the declaration of a ―concern‖. The actual specification of the concern is left to any suitable
368 modeling language which is capable of capturing such concerns and is compliant with the ISO/IEC
369 42010:2007 standard like ArchiMate.
370
371 ArchiMate is a modeling standard following the definitions and relationships of the concepts of
372 concern, viewpoint, and view proposed by the ISO/IEC 42010:2007 standard for architecture
373 descriptions. The ArchiMate framework is capable of defining stakeholder concerns in viewpoints,

74
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

374 while the ArchiMate language is capable of addressing these with corresponding views showing
375 the right aspects of the architecture conforming to defined viewpoints.
376
377 The core of TOGAF is basically a process, the so-called Architecture Development Method (ADM)
378 describing viewpoints, techniques, and reference models, but not a complete formal language.
379 ArchiMate describes viewpoints and provides a formal modeling language, including a (graphical)
380 notation.
381

382
383 Figure 32: TOGAF ADM model

384
385 TOGAF and ArchiMate overlap in their use of viewpoints, and the concept of an underlying
386 common repository of architectural artifacts and models; i.e., they have a firm common foundation.
387 Both complement each other with respect to the definition of an architecture development process
388 and the definition of an enterprise architecture modeling language.
389
390 ArchiMate 1.0 chiefly supports modeling of the architectures in Phases B, C, and D of the TOGAF
391 Architecture Development Method (ADM). The resulting models are used as input for the
392 subsequent ADM phases. However, modeling concepts specifically aimed at the other phases are
393 still missing in the language.
394

75
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

395 Those three main standards (ISO/IEC 42010, TOGAF and Archimate) which are domain
396 independent can also be used to express the SG-CG/RA work‘s group for the M/490 mandate.
397 However, this method has a major drawback of using Software and system engineering specific
398 vocabulary and a new specification language most standardization members are not familiar with.
399 Therefore, we suggest the use of the architecture related, non-domain specific standards is
400 possible but suggest fort his document to adhere to the known principles and provide and example
401 in the how to use the three standards for a Smart grid Use Case in the annex.
402
Business Architecture
Business

Information Architecture

Application
Architecture Function

Data
Information
Architecture

Technology Architecture Communication

Component
403
404 Figure 33: Mapping of GWAC dimensions onto Archimate

405
406 Figure 33 provides a representation of the different aspects form the GWAC stack and dimension
407 onto the Archimate view for a reference architecture model. Figure 34 shows that additionally to
408 the three main dimensions, finer viewpoints addressing more precise objects exist. Figure 35
409 shows how the model can be applied in a multi-dimensional view if e.g. an unbundled European
410 utility must be modeled. This approach shows that existing, non-domain related views and
411 methodologies can be applied in conjunction with the SGAM and its views.
412

76
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

413
414 Figure 34: Archimate representation of the architectural viewpoints

415

416
417 Figure 35: interdependencies between the three most important dimensions with Archimate

77
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

418
419 Figure 36: Multi-dimensional view for unbundled utility

420 B.2.6 Examples and Mappings of existing solutions

421 Possible examples on how the SGAM model can be applied to existing solutions and meta-models
422 from ETSI or IEC can be seen in the following graphics. A mapping was made with respect to the
423 existing models; in case of gaps - these need to be fixed or addressed in general.

78
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

424 B.2.6.1 Example: ETSI “M2M Architecture”

425
426 Figure 37: SGAM Mapping of ETSI M2M Architecture

427
428 Most of the issues could be directly addressed; a direct mapping for the information model was not
429 possible.

430 B.2.6.2 Example: IEC SG3 “Mapping Chart”

431 Case B from the IEC SG 3 addresses the existing model from the IEC SG group which is also
432 covered in the IEC roadmap and the standards mapping tool for smart grid solutions.

79
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

433
434 Figure 38: SGAM Mapping of IEC SG3 Mapping Chart

435
436 This example also shows that even information layers and their corresponding standards can be
437 mapped if the original meta-model addresses the SGAM relevant viewpoint. The model is sliced
438 just as the ETSI model; therefore, needed viewpoint for the different stakeholders (e.g.
439 communications parts of existing models) can be easier identified.

440 B.2.6.3 Example: IEC TC57 “RA for Power System Information Exchange”
441 Last example is the existing seamless integration architecture (SIA) from the IEC TC 57 which
442 covers all the relevant smart grid standards form TC 57 in a layered architecture and links to other
443 relevant standards from TCs outside 57.
444

80
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

445
446 Figure 39: SGAM Mapping of IEC TC57 Reference Architecture
447 for Power System Information Exchange

448 The SIA has taken most of the SGAM architectural viewpoints into account and provides for easy
449 mapping onto SGAM.
450 B.2.7 Findings
451 As those, from an European perspective main relevant examples clearly show, is that the SGAM
452 meta model with its viewpoints provides a proper way to represent existing solutions which have
453 been developed by the various standardization bodies and stakeholder groups. One important
454 additional conceptual model which should be taken into account fort his SGAM document is the
455 NIST Conceptual model as international alignment of initiatives is of high interest. A future version
456 will address this model.
457
458 The SGAM model provides, additionally, a good way of both categorizing existing models and
459 identifying gaps. Categorizing in terms of finding out what the specific scope of an existing model is
460 and, using this, finding out about is proper application and on the other hand, finding out what is
461 missing and might need to be addressed.
462 B.2.8 Mapping of business transactions
463 Architectures in general provide services and functionality which is addressed by the
464 corresponding technical or business processes. For the reference architecture, use cases with
465 systems within this architecture are of highest importance. Starting at the function layer, the
466 processes are mapped onto the SGAM, sub-functions are then distributed and things are drilled
467 down to components, information and communication model. Using this, not only existing
468 processes and use cases can be mapped onto the SGAM but also onto the existing reference

81
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

469 architectures from IEC or ETSI and the SGAM can be used as alignment ontology for the
470 processes and use cases between those models like common semantic mediator.
471

82
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Annex C
Business Architecture and Conceptual Model
472 This Annex is introducing informative reference on the following elements:
473  The new version of the European Smart Grids Conceptual Model that has been developed
474 by the SG-CG/RA Work Group to take into account the comments on the previous version
475 (v2.0) of this report as well as the need to address the Flexibility Concept. This version has
476 not been introduced in the main section of this report for reasons explained in 6.3.5
477  The European Harmonized Electricity Market Role Model and the list of Actors involved.
478  A clarification of the relationship between the domains of the European Smart Grids
479 Conceptual Model and the European Harmonized Electricity Market Role Model.

480 C.1 Conceptual Model

481 C.1.1 Introduction

482 The electrical energy system is currently undergoing a paradigm change, that has been affected by
483 a change from the classical centralistic and top down energy production chain "Generation",
484 "Transmission", "Distribution" and "Consumption" to a more decentralized system, in which the
485 participants change their roles dynamically and interact cooperative. In the future decentralized
486 energy system, distributed energy resources and consumers produces will become key elements.
487 The development of the concepts and architectures for an European Smart Grid is not a simple
488 task, because there are various concepts and architectures, representing individual stakeholders
489 viewpoints. To imagine the paradigm change from the current situation to future situation, both
490 situations are described below:
491
492 The current situation can best be described as:
493 Supply follows demand
494 One-way energy flow in the grid:
495 bulk generation => transmission => distribution => consumption.
496 Capacity in distribution networks is dimensioned on peak (copper plate), resulting in
497 (almost) no network congestion
498 Capacity required in the lower voltage range is predictable, since it is only based on energy
499 usage.
500
501 The future situation can best be described as:
502 Demand follows supply, due to the insertion of renewables, which are by nature of
503 intermittent character
504 Electrification of society in order to meet 202020 objectives, which will lead to a further
505 growth of electricity demand
506 Two way energy flow in the grid: consumers will also produce (e.g. by means of a
507 photovoltaic cells, micro combined heat and power installations, etc.) and supply their
508 surplus to the grid
509 A future grid will need to support:
510 o Multiple producing consumers, that will aggregate their
511 electrical surplus to an Virtual Power Plant.
512 o Electrical cars, in such a way that the grid won't fail when they want to charge
513 simultaneously or use their batteries for energy storage
514 to use in situations with high consumption or high production.
515 o The integration of all kinds of distributed energy resources (wind, solar, …)

83
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

516 A grid which will have to fulfill these requirements, not only by expanding grid capacity
517 (which might become very costly due to the expected increase of peaks), but also by
518 implementing smartness via ICT solutions, in a way that it will fully support current and
519 future market processes.
520 Furthermore a future grid will need the Smart Grid functions, described in the EG1 report of
521 the CEN/CENELEC/ETSI Joint Working Group.
522
523 In the future situation it will have more and very different dynamics in the grid, as in the current
524 situation, because the dynamics results from the distributed (renewable) energy resources, that
525 behavior are difficult to predict. These increased dynamics will require a much more flexible (and
526 intelligent) approach towards the management of electricity supply and demand. Furthermore, the
527 future situation should also allow for new market models and let all kinds of customers participate
528 in the trade of electricity energy.
529
530 Flexibility, thus, will be key. Where until today in the current ―supply follows demand‖ model,
531 flexibility was offered in bulk generation, in the future in the ―demand follows supply‖ model the
532 flexibility must be equivalent offered on both sides (generation (centralized and decentralized) and
533 consumption (e.g. demand side management)).
534
535 Therefore the ICT infrastructure and ICT solutions, which enables the required flexibility on
536 demand and supply side in a fully interchangeable way, becomes a key component of the smart
537 grid and therefore it will be become part of the smart grid eco system.
538
539 This paragraph defines the conceptual model of the European smart grid. This conceptual model
540 should be regarded as the initial ―umbrella‖ model from which all future frameworks, architectures
541 and standards could be derived from, and from which also existing standards could be (re)
542 positioned. This conceptual model should also be able to act as a basis for future market models
543 and related regulation, in order to guarantee that market models are supported by the right
544 architectures and standards.
545
546 The Reference Architecture for the Smart Grid must support several stakeholders in building the
547 European smart grid, and each stakeholder today has a different view on this smart grid. The more
548 and more decentralized energy production requires new methods to guarantee the stable operation
549 of the electrical part of the smart grid.
550
551 The development of the future smart grid requires the collaboration of different stakeholders. The
552 future smart gird technology is the equivalent integration of power system management technology
553 and information and communication technology (IT/OT convergence).
554
555 The conceptual model attempts to be the common framework, thereby enabling this convergence
556 and facilitating the dialog between all these stakeholders, resulting in an aligned and consistent
557 smart grid.
558
559 It is the basis of a common dictionary, necessary to talk the same language. The Conceptual
560 Model will be this common dictionary and describe the key concepts in the European smart grid.
561 C.1.2 Historical context
562 A starting point for the development of a European conceptual model was the reuse of existing
563 know-how to avoid redundant work and to build up on it. This led in the previous version of this
564 report initially to the full adoption of the US conceptual model, defined by NIST. This model
565 provides a high-level framework for the Smart Grid that defines seven high-level domains (Bulk
566 Generation, Transmission, Distribution, Customers, Operations, Markets and Service Providers).
567

84
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

568 The NIST model shows all the communications and energy/electricity flows connecting each
569 domain and how they are interrelated. Each individual domain is itself comprised of important
570 smart grid elements (actors and applications) that are connected to each other through two-way
571 communications and energy/electricity paths.
572
573 Due to strong European focus on decentralized energy generation, the original NIST model was
574 extended by a new ―Distributed Energy Resources‖ Domain (see 0), for the following reasons:
575 Distributed Energy Resources require a new class of use cases
576 In order to comply to future anticipated regulation and legislation explicit distinction of
577 Distributed Energy Resources will be required
578 Distributed Energy Resources represent the current situation
579
580 Consistent and clear criteria to separate the new DER Domain from the existing Domains,
581 especially from Bulk Generation and the Customer Domain were identified.
582

583
584 Figure 40: EU extension of the NIST Model

585 Review comments and discussion on the M490 report version 2.0 led to the insight that a rigid
586 separation of the DER domain from the customers domain, would actually create complexity and
587 would rule out required flexibility that emerges in the energy transition from customers both
588 consuming and producing energy.
589
590 As a result of these discussions it was decided that the European conceptual model should
591 incorporate/ enable the flexibility concept that was defined by SG-CG/SP.
592
593 The European Flexibility Concept
594
595 The objective of the flexibility concept, shown in Figure 41, is to describe the flexibility (demand
596 and generation) methods for technical and commercial operations.
597

85
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

598
599
600 Figure 41: Flexibility concept (result of WGSP)

601 In the flexibility concept the management (control) of flexible demand and supply is fully
602 interchangeable at the Smart Grid Connection Point (SGCP); in principle any connected party
603 (Smart Customer) with flexible generation, consumption and/or storage.
604
605 In the elaboration of the flexibility model commercial and technical flexibilities are identified, leading
606 to commercial flexibilities for interaction with the market (e.g. contracts, pricing) and technical
607 flexibilities (control signals, technical information exchange) for interaction with grid operations.
608 This is shown in Figure 42.

609
610
611 Figure 42: Technical & commercial flexibilities

612 With the historical background in mind, as described above, this led to the formulation of starting
613 principles and to a clear definition of an (evolved) European Conceptual Model, addressing all
614 stakeholders‘ interests.
615 C.1.3 Starting Principles
616 Defining a European conceptual model, from which architectures and standards can be derived,
617 requires explicit starting principles, to be used as acceptance criteria for the Conceptual Model.
618 These starting principles are described in this paragraph.
619
620 The evolution of the European Conceptual Model in a way that it is aligned with the rather technical
621 aspects of the extended NIST Model and with the rather future energy markets aspects of the SG-

86
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

622 CG/SP Flexibility Concept is guaranteed by the following approach and procedure, which is based
623 on the 5 principles below.
624
625 Approach
626 Domains are a grouping of roles and actors. So roles and actors in the domains of both models
627 can be used as a fix point for the alignment of the models. To identify the same roles and actors in
628 the domains of both models, the European harmonized electricity market role model will be used.
629 The alignment is based in detail on the following 5 principles, which form the basis for the
630 development of the EU Conceptual Model (described in C.1.4).
631
632 Principle 1: Extract business roles and system actors from the EU extended NIST
633 conceptual model
634
635 The EU extension of the NIST conceptual model is organized in domains. These domains group
636 business roles and thereby system actors which perform tasks in these roles as shown in Figure
637 43. This figure illustrates the meta-model used for the European conceptual model for Smart Grids.
638
groups ► is assumed by ►
Business Role
Domain System Actor
(Business Actor)
◄ part of ◄ performs task in
639
640
641 Figure 43: Meta-model for the European conceptual model for Smart Grids

642 The approach to model the conceptual model based on business roles and related system actors
643 ensures ‗compatibility‘ between market and technologies/standards. Section 6.1 provides a more
644 detailed description of this approach.
645
646 Principle 2: Alignment with the European electricity market
647
648 In the WGSP flexibility model, the business roles are based on the European harmonized
649 electricity market role model, developed by ENTSO-E, ebIX and EFET and defined in [ENTSO-E
650 2011]. This ensures alignment of technologies/standards which are developed from this model with
651 the European electricity market. The grouping of roles of the harmonized electricity market role
652 model into the domains of the WGSP flexibility model supports initial understanding of the
653 European electricity market (at a higher level of abstraction than the 36 roles identified in [ENTSO-
654 E 2011]).
655
656 Principle 3: Support central and distributed power system deployments
657
658 The EU conceptual model (described in the next part) must support fully centralized, fully
659 distributed and hybrid deployments of the power system. Energy resources connected to all levels
660 of the grid are relevant in Smart Grids, ranging from bulk generation and industrial loads down to
661 distributed energy resources and domestic loads. Also support for grids outside the traditional
662 public infrastructure should be supported, as e.g. analyzed in the use cases of the workgroup on
663 sustainable processes from the SG-CG. Examples include (non-public) grids used in local energy
664 cooperatives, ranging from industrial areas (sea- and airports) to agricultural areas (e.g. in the
665 greenhouse sector).
666

87
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

667
668 Figure 44: Evolution of centralized/ decentralized power systems deployments

669 Principle 4: Support micro grids and a Pan European Energy Exchange System (PEEES)
670
671 The objective of micro grids is to start the optimization of the grid as locally as possible, e.g. to find
672 a balance between production and consumption, in order to avoid transmission losses and
673 increase transmission reliability through ancillary services such as reserves volt/var support, and
674 frequency support. For other objectives to be met for micro grids see also use case WGSP-0400.
675
676 PEEES are essential to realizing the large-scale energy balance between regions with a low-loss
677 wide-area power transmission.
678
679 The Pan European Energy Exchange System (PEEES), includes technologies in the transport
680 network for low-loss wide-area power transmission systems (e. g. high-voltage direct current
681 transmission, HVDC), better realizing the large-scale energy balance between the regions, which is
682 essential due to the constantly changing weather situation, which has a significant influence on the
683 power generation capacity of different regions.
684
685 The PEEES is here to be understood as a abstract model for further discussions to cover the
686 concepts for low-loss wide-area power transmission systems. As an example of this, the "Modular
687 Development Plan of the Pan-European Transmission System 2050" of the e-HIGHWAY2050
688 Project Consortium can be mentioned here. [ENTSO-E 2012]
689
690 Principle 5: Support providing flexibility in electricity supply and demand
691
692 Providing flexibility in electricity supply and demand – on all levels in the power system – is
693 paramount for integration of renewable energy sources in the Smart Grid. The EU conceptual
694 model must support the use cases identified by the workgroup on sustainable processes on
695 providing and using flexibility.
696
697 C.1.4 European Conceptual Model of Smart Grids
698 The definition of the European conceptual model of Smart Grids is defined through grouping of
699 (European harmonized) roles and system actors, in line with the European electricity market.
700 Figure 45 depicts the European conceptual model for the Smart Grid. The model consists of four
701 main domains, Operations, Grid Users, Markets, and Energy Services.
702
703 Each of these domains contains one or more subdomains which group roles which can be
704 identified in the European electricity market. For this the European harmonized electricity market

88
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

705 role model developed by ENTSO-E, ebIX and EFET is used as defined in [ENTSO-E 2011] and
706 introduced in C.2. Detailed definitions of the domains of the European conceptual model for the
707 Smart Grid and the relationship to the role model used is provided annex C.2
708
709 Operations and Grid Users are domains which are directly involved in the physical processes of
710 the power system: electricity generation, transport/distribution and electricity usage. Also, these
711 domains include (embedded) ICT enabled system actors. The Markets and Energy Services
712 domains are defined by roles and (system) actors and their activities in trade of electricity products
713 and services (markets), and the participation in the processes of trade and system operations
714 representing grid users (energy services).
715
Markets

Flexibility Market Grid Capacity Market Energy Market

facilitates and
coordinates trade via ▲
trade in ▲

Operations Energy Services

facilitates and
coordinates trade by►
System Operations Energy Trade Flexibility Trade /
Balancing
Metering Operations Grid Capacity Trade Responsibilities

Grid Operations Smart Grid

Connection Point
provides energy
Transmission Grids services to ▼

Distribution Grids Grid Users

... Production, storage and consumption

Bulk Generation C&I Loads

Legend:
DER Domestic Loads
Domain transports power
from and to ►
Subdomain Storage Electric Vehicles

System Actor
...

716
717 Figure 45: European Conceptual Model for the Smart Grid

718 Operations
719 The Operations domain is defined by roles and actors related to the stable and safe operations of
720 the power system; the domain ensures the usage of the grid is within its constraints and facilitates
721 the activities in the market. Grid Operations, System Operations and Metering Operations are
722 identified as sub-domains in the Operations domain. System actors in this domain include grid
723 assets such as transformers, switchgear, etc. in Transmission and Distribution Grids, metering
724 systems and control centre systems.
725
726 Grid Users
727 The Grid Users domain is defined by roles and actors involved in the generation, usage and
728 possibly storage of electricity; from bulk generation and commercial and industrial loads down to
729 distributed energy resources, domestic loads, etc. The roles and actors in this domain use the grid
730 to transmit and distribute power from generation to the loads. Apart from roles related to the

89
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

731 generation, load and storage assets, the Grid Users domain includes system actors such as
732 (customer) energy management and process control systems.
733
734 Energy Services
735 The Energy Services domain is defined by roles and actors involved in providing energy services
736 to the Grid Users domain. These services include trading in the electricity generated, used or
737 stored by the Grid Users domain, and ensuring that the activities in the Grid Users domain are
738 coordinated in e.g. the system balancing mechanisms and CIS systems.
739
740 Through the Energy Services domain the Grid Users domain is connected to activities such as
741 trade and system balancing. From the Grid Users domain, flexibility in power supply and demand is
742 provided. This flexibility is used for system balancing (through e.g. ancillary services, demand
743 response, etc.) and trading on the market. Also roles are included which are related to trade in grid
744 capacity (as currently is traded on the transmission level).
745
746 Example (system) actors in this domain include systems for customer relationship management,
747 and billing, trading systems, etc.
748
749 I.e. the roles and actors from the Energy Services domain facilitate participation in the electricity
750 system, by representing the Grid Users domain in operations (e.g. balance responsibility) and
751 markets (trading).
752
753 Markets
754 The Market domain is defined by roles and actors which support the trade in electricity (e.g. on day
755 ahead power exchanges) and other electricity products (e.g. grid capacity, ancillary services). Sub
756 domains which are identified in this domain are: Energy Market, Grid Capacity Market, and
757 Flexibility Market. Activities in the Market domain are coordinated by the Operations domain to
758 ensure the stable and safe operation of the power system. Example (system) actors in this domain
759 are trading platforms.

760 C.1.4.1 Alternative Figure: European Conceptual Model for the Smart Grid
761 The figure below is provided as a possible alternative for Figure 45. The main difference is in
762 presentation: 1) in the grouping of grid assets (by introducing the transmission and distribution
763 domains which only contains system actors) and 2) in different naming of the domains Grid Users
764 and Energy Services. This is to be discussed in the next meeting of the architecture workgroup in
765 Bilbao. The essence is the same as the figure above, however for commitment a graphical
766 representation is chosen to accommodate more were we are coming from.
767

90
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Markets

Flexibility Market (imbalance) Grid Capacity Market Energy (c0mmodity) Market

facilitates and
coordinates trade via ▲
trade in ▲

Operations Energy Services

facilitates and
coordinates trade by►
System Operations Metering Operations Energy Trade Flexibility
Operations
Transmission Operations Distribution Operations Customer Services (balancing)

provides grid
access to▼ provides energy
operates ▼ operates ▼
services to ▼
Smart Grid
Transmission Distribution Connection Point

HV Transmission MV/LV Transmission Grid Users / Flexibility Provider

Bulk Generation Loads (usage)

transports power
transports power DER Storage
Legend: from and
and to ►
to ►
from
Domain

Subdomain /
System Actor

768
769 Alternative Figure: European Conceptual Model for the Smart Grid

770 The table below shows which domains contain business actors and which contain system actors in
771 this alternative figure.
772
773 Table C-1: Mapping of domains to roles and actors

Domain ENTSO-E role Business Actor System Actor

Market + + +
Operations + + +
Service Provider + + +
Flexibility Provider + + +
Transmission n/a +
Distribution n/a +
774
775 C.1.5 Alignment
776 This paragraph identifies and describes the required alignment with other relevant initiatives/
777 activities that are required for building a smart grid based on standards and common reference
778 architectures.

779 C.1.5.1 Alignment with the EU flexibility concept

780 In the energy transition, Europe is focusing on managing flexibility of demand and supply.
781 This concept of flexibility is elaborated in the M490 WGSP, resulting in several related use cases.
782 These use cases on ‗providing flexibility‘ concern control/management of flexible demand & supply.
783
784 Flexibility in demand and supply is provided by ‗smart customers. In the conceptual model as
785 described in paragraph C.1.4 this is reflected by the Grid Users domain, which provides flexibility.
786 This flexibility is used by parties related to grid/power system management and electricity markets.

91
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

787
788 Operating this flexibility is performed by an actor ‗Flexibility Operator‘. In annex xx this use case is
789 analyzed in the context of the European Harmonized Electricity Market Role Model (HEM-RM)
790 which underpins the European conceptual model for Smart Grids. The Flexibility Operator relates
791 to one of various roles in the Energy Services domain. Depending on the type of interaction with
792 the ‗smart customers‘ in the use cases of WGSP, the Flexibility Operator acts in the Resource
793 Provider, Balance Responsible Party, Balance Supplier or Grid Access Provider role from [ENTSO
794 2011].
795
796 In the flexibility market flexibility in demand and supply (interchangeable) will be traded, by services
797 providers with balance responsibilities that have access to this (wholesale) market.

798 C.1.5.2 Alignment with SG-CG/SP on Sustainable Processes

799 The SG-CG/SP Work Group on Sustainable Processes, in collecting use cases, has defined
800 generic use cases. The deliverables coming from WG SP from these uses cases are:
801 Actors (business actors and system actors)
802 Identification and interaction between actors
803 Processes
804 Technical requirements
805
806 Based on these deliverables, SG-CG/RA is able to identify existing standards via the SGAM
807 framework (see 7.2), to be possible modified and used in the smart grid standards. In future work a
808 more refined functional architecture with well-defined interfaces and services definitions between
809 market parties will be defined. Since actors and transaction between actors will form the basis for
810 this reference architecture, alignment is guaranteed.
811
812 In the future smart grid eco system a well-defined interaction between the capacity market and the
813 energy market will be crucial. The traffic light concept as defined by WGSP will form the basis for
814 this. This interaction will be modeled between roles (and subsequently parties) as identified in the
815 EU Harmonized Electricity Market Role Model, leading to required information exchange on the
816 Smart Grid Connection Point (SGCP), being the information interface between the grid users‘
817 domain and the other domains.

818 C.1.5.3 Alignment with NIST, SGIP, SGAC

819 Since market models in US and EU differ, it is important to derive standards which are, as much as
820 possible, market model independent. Also the Harmonized Electricity Market Role Model as
821 defined by ENTSO-E/ebIX/EFET is currently not used in the US. Alignment therefore is created
822 and maintained on the basis of common actor list and interactions between actors, driven from use
823 case analysis. From this common International standards can be derived and interoperability is
824 achieved. There for even if the market models and the conceptual model differ (grouping of roles
825 and actors), the same standards may be applicable (although priorities may differ). (The alignment
826 of actor lists and interactions between actors is currently on going work extended into 2013).

827 C.1.5.4 Alignment with Harmonized Electricity Market Role Model

828 The Harmonized Electricity Market role model has been picked up for use, both by WGSP as
829 WGRA, leading to a consistent and solid approach for all future modeling exercises. From
830 discussion within the M490 groups, as well in market model discussions (EG3) new roles in this
831 model may become necessary. It therefore will be required to come to working arrangements with
832 ENTSO-E on this, in order to establish adequate version control of the Harmonized Electricity
833 Market Role Model.

92
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

834 C.1.5.5 Alignment with EU market model developments (EG3)

835 In the EU standardization activities, the Harmonized Electricity Market Role Model (HEM-RM) is
836 promoted to be used to map responsibilities of market parties to the harmonized roles. This means
837 that the interaction between actors, as defined by WGSP and translated to interaction between
838 roles, can define the interaction between market parties.
839
840 The task force smart grid (EG3) recommended the EU commission that in the market model
841 discussions, whatever the outcome will be, the roles & responsibilities of market parties, related to
842 the market models, will be mapped onto the HEM-RM roles. In this way interaction between actors
843 and roles can be translated tot interaction between market parties.
844
845 In this way it becomes clear which standards on interfaces and business services are required, and
846 is alignment between market model development and M490 standards.
847 C.1.6 Conclusions
848 As a conclusion from the above:
849 The conceptual model is solid and well defined, based on roles and actors
850 It accommodates the flexibility concept
851 It bridges the 2 approaches/cultures coming from power system management and IT
852 technology; it forms a common ground for cooperation.
853 It accommodates alignment between M/490 Standardization activities and market model
854 discussions
855 It identifies the way alignment should be reached with US (NIST, SGIP, SGAC)
856

857 C.2 The European Harmonized Electricity Market Role Model

858 The text in this section is an excerpt taken from the [ENTSO-E 2011] Harmonized Electricity
859 Market Role Model, and included for informational purpose. Please refer to the original document
860 for more detailed information on this role model.
861
862 A “Role Model” provides a common definition of the roles and domains employed in the
863 electricity market which enables people to use a common language in the development of
864 information interchange.
865
866 A party on the market may play several roles, for example a TSO frequently plays both the
867 role of System Operator and the role of Imbalance Settlement Responsible. However two
868 different roles have been defined since these roles are not always played by the same party.
869 Even in a large organisation the roles may not be played by the same business unit.
870 Consequently it is necessary to clearly define the roles in order to be in a position to correctly
871 use them as required. It is important to differentiate between the roles that can be found on a
872 given marketplace and the parties that can play such roles. ENTSO-E and the associated
873 organisations have identified a given role whenever it has been found necessary to
874 distinguish it in an information interchange process.
875
876 The model consequently identifies all the roles that intervene in the exchange of information
877 in the electricity market. These roles define the external interfaces managed by a party for
878 given processes. It also identifies the different domains that are necessary in the electricity
879 market for information interchange. A domain represents a grouping of entities with common
880 characteristics.
881
882 The objective of decomposing the electricity market into a set of autonomous roles and
883 domains is to enable the construction of business processes where the relevant role

93
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

884 participates to satisfy a specific transaction. Business processes should be designed to

885 satisfy the requirements of the roles and not of the parties.
886
887 C.2.1 Role model – role definitions
888 The table below quotes the definitions from [ENTSO-E 2011] of all the roles in the European
889 harmonized electricity market role model.
890
Role Description
Balance Responsible Party A party that has a contract proving financial security and
identifying balance responsibility with the Imbalance
Settlement Responsible of the Market Balance Area entitling
the party to operate in the market. This is the only role
allowing a party to nominate energy on a wholesale level.

Additional information: The meaning of the word ―balance‖ in

this context signifies that that the quantity contracted to
provide or to consume must be equal to the quantity really
provided or consumed.

Equivalent to ―Program responsible party‖ in the

Netherlands. Equivalent to ―Balance group manager‖ in
Germany. Equivalent to ―market agent‖ in Spain.
Balance Supplier A party that markets the difference between actual metered
energy consumption and the energy bought with firm energy
contracts by the Party Connected to the Grid. In addition the
Balance Supplier markets any difference with the firm energy
contract (of the Party Connected to the Grid) and the
metered production.

Additional information: There is only one Balance Supplier

for each Accounting Point.
Billing Agent The party responsible for invoicing a concerned party.
Block Energy Trader A party that is selling or buying energy on a firm basis (a
fixed volume per market time period).
Capacity Coordinator A party, acting on behalf of the System Operators involved,
responsible for establishing a coordinated Offered Capacity
and/or NTC and/or ATC between several Market Balance
Areas.
Capacity Trader A party that has a contract to participate in the Capacity
Market to acquire capacity through a Transmission Capacity
Allocator.

Note: The capacity may be acquired on behalf of an

Interconnection Trade Responsible or for sale on secondary
capacity markets.
Consumer A party that consumes electricity.

Additional information: This is a Type of Party Connected to

the Grid.

94
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Role Description
Consumption Responsible Party A party who can be brought to rights, legally and financially,
for any imbalance between energy nominated and
consumed for all associated Accounting Points.

Additional information: This is a type of Balance Responsible

Party.
Control Area Operator Responsible for :
1. The coordination of exchange programs between its
related Market Balance Areas and for the exchanges
between its associated Control Areas.
2. The load frequency control for its own area.
3. The coordination of the correction of time deviations.
Control Block Operator Responsible for :
1. The coordination of exchanges between its
associated Control Blocks and the organisation of the
coordination of exchange programs between its
related Control Areas.
2. The load frequency control within its own block and
ensuring that its Control Areas respect their
obligations in respect to load frequency control and
time deviation.
3. The organisation of the settlement and/or
compensation between its Control Areas.
Coordination Center Operator Responsible for :
1. The coordination of exchange programs between its
related Control Blocks and for the exchanges
between its associated Coordination Center Zones.
2. Ensuring that its Control Blocks respect their
obligations in respect to load frequency control.
3. Calculating the time deviation in cooperation with the
associated coordination centers.
4. Carrying out the settlement and/or compensation
between its Control Blocks and against the other
Coordination Center Zones.
Grid Access Provider A party responsible for providing access to the grid through
an Accounting Point and its use for energy consumption or
production to the Party Connected to the Grid.
Grid Operator A party that operates one or more grids.
Imbalance Settlement Responsible A party that is responsible for settlement of the difference
between the contracted quantities and the realised quantities
of energy products for the Balance Responsible Parties in a
Market Balance Area.

Note: The Imbalance Settlement Responsible has not the

responsibility to invoice. The Imbalance Settlement
Responsible may delegate the invoicing responsibility to a
more generic role such as a Billing Agent.

95
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Role Description
Interconnection Trade Responsible Is a Balance Responsible Party or depends on one. He is
recognised by the Nomination Validator for the nomination of
already allocated capacity.

Additional information: This is a type of Balance Responsible

Party.
Market Information Aggregator A party that provides market related information that has
been compiled from the figures supplied by different actors in
the market. This information may also be published or
distributed for general use.

Note: The Market Information Aggregator may receive

information from any market participant that is relevant for
publication or distribution.
Market Operator The unique power exchange of trades for the actual delivery
of energy that receives the bids from the Balance
Responsible Parties that have a contract to bid. The Market
Operator determines the market energy price for the Market
Balance Area after applying technical constraints from the
System Operator. It may also establish the price for the
reconciliation within a Metering Grid Area.
Meter Administrator A party responsible for keeping a database of meters.
Meter Operator A party responsible for installing, maintaining, testing,
certifying and decommissioning physical meters.
Metered Data Aggregator A party responsible for meter reading and quality control of
the reading.
Metered Data Collector A party responsible for the establishment and validation of
metered data based on the collected data received from the
Metered Data Collector. The party is responsible for the
history of metered data for a Metering Point.
Metered Data Responsible A party responsible for the establishment and qualification of
metered data from the Metered Data Responsible. This data
is aggregated according to a defined set of market rules.
Metering Point Administrator A party responsible for registering the parties linked to the
metering points in a Metering Grid Area. He is also
responsible for maintaining the Metering Point technical
specifications. He is responsible for creating and terminating
metering points.
Merit Order List (MOL) Responsible Responsible for the management of the available tenders for
all Acquiring System Operators to establish the order of the
reserve capacity that can be activated.

96
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Role Description
Nomination Validator Has the responsibility of ensuring that all capacity nominated
is within the allowed limits and confirming all valid
nominations to all involved parties. He informs the
Interconnection Trade Responsible of the maximum
nominated capacity allowed. Depending on market rules for
a given interconnection the corresponding System Operators
may appoint one Nomination Validator.
Party Connected to the Grid A party that contracts for the right to consume or produce
electricity at an Accounting Point.
Producer A party that produces electricity.

Additional information: This is a type of Party Connected to

the Grid.
Production Responsible Party A party who can be brought to rights, legally and financially,
for any imbalance between energy nominated and produced
for all associated Accounting Points.

Additional information: This is a type of Balance Responsible

Party.
Reconciliation Accountable A party that is financially accountable for the reconciled
volume of energy products for a profiled Accounting Point.
Reconciliation Responsible A party that is responsible for reconciling, within a Metering
Grid Area, the volumes used in the imbalance settlement
process for profiled Accounting Points and the actual
metered quantities.

Note: The Reconciliation Responsible may delegate the

invoicing responsibility to a more generic role such as a
Billing Agent.
Reserve Allocator Informs the market of reserve requirements, receives
tenders against the requirements and in compliance with the
prequalification criteria, determines what tenders meet
requirements and assigns tenders.
Resource Provider A role that manages a resource object and provides the
schedules for it.
Scheduling Coordinator A party that is responsible for the schedule information and
its exchange on behalf of a Balance Responsible Party. For
example in the Polish market a Scheduling Coordinator is
responsible for information interchange for scheduling and
settlement.

97
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Role Description
System Operator A party that is responsible for a stable power system
operation (including the organization of physical balance)
through a transmission grid in a geographical area. The
System Operator will also determine and be responsible for
cross border capacity and exchanges. If necessary he may
reduce allocated capacity to ensure operational stability.
Transmission as mentioned above means ―the transport of
electricity on the extra high or high voltage network with a
view to its delivery to final customers or to distributors.
Operation of transmission includes as well the tasks of
system operation concerning its management of energy
flows, reliability of the system and availability of all necessary
system services‖. (Definition taken from the ENTSO-E
RGCE Operation handbook Glossary).

Note: additional obligations may be imposed through local

market rules.
Trade Responsible Party A party who can be brought to rights, legally and financially,
for any imbalance between energy nominated and
consumed for all associated Accounting Points.

Note: A power exchange without any privileged

responsibilities acts as a Trade Responsible Party.
Additional information: This is a type of Balance Responsible
Party.
Transmission Capacity Allocator Manages the allocation of transmission capacity for an
Allocated Capacity Area. For explicit auctions: The
Transmission Capacity Allocator manages, on behalf of the
System Operators, the allocation of available transmission
capacity for an Allocated capacity Area. He offers the
available transmission capacity to the market, allocates the
available transmission capacity to individual Capacity
Traders and calculates the billing amount of already
allocated capacities to the Capacity Traders.
891

892 C.3 Relationship between the domains of the conceptual model

893 and the European harmonized electricity market role model
894 Figure 46 below shows the relationship between the domains of the conceptual model and the
895 European harmonized electricity market role model.
896

98
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Markets

Flexibility Market Grid Capacity Market Energy Market

Reserve Allocator Capacity Coordinator Market Information Aggregator
Merit Order List Responsible Transmission Capacity Allocator Market Operator
Nomination Validator

facilitates and
coordinates trade via ▲
trade in ▲

Operations Energy Services

System Operations Energy Trade

System Operator Balance Supplier
Control Area Operator Block Energy Trader
Control Block Operator
Coordination Center Operator Grid Capacity Trade
Imbalance Settlement Responsible Capacity Trader
Reconciliation Responsible facilitates and Interconnection Trade Responsible
coordinates trade by►
Metering Operations
Flexibility Trade
Meter Administrator / Balancing Responsibilities
Meter Operator Balance Responsible Party
Metered Data Aggregator Consumption Responsible Party
Metered Data Collector Production Responsible Party
Metered Data Responsible Trade Responsible Party
Reconciliation Accountable
Grid Operations Scheduling Coordinator
Grid Operator Resource Provider
Grid Access Provider
Metering Point Administrator
provides energy
services to ▼

Grid Users

Legend: Production, storage and consumption

Domain Party Connected to the Grid
Subdomain Consumer
transports power
Role from and to ► Producer
897
898 Figure 46: Relationship between the domains of the conceptual model and the European
899 harmonized electricity market role model

900
901 Note that in the figure above, the Billing Agent role is not included in the relationship between
902 domains of the conceptual model and the harmonized electricity market roles due to its generic
903 nature. In [ENTSO-E 2011] the Billing Agent role is not associated to any other role.

904 C.4 Relation between the flexibility operator actor and the
905 European harmonized electricity market role model
906 The use cases identified by the SG-CG/SP Sustainable Processes Work Group on ‗providing
907 flexibility‘ concerns control/management of flexible demand & supply. In these use case, flexibility

99
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

908 in demand and supply is provided by ‗smart customers‘, for usage in use cases related to e.g.
909 system balancing, network constraint management, voltage / var optimization, network restoration
910 and black start, power flow stabilization, market balancing.
911
912 I.e. the flexibility is used by parties related to grid / power system management and/or electricity
913 markets. Pooling of this flexibility is performed by a so called ‗Flexibility Operator‘. The flexibility
914 use cases cover several means of interacting with ‗smart customers‘, including:
915
916 - Communication of price signals, tariffs and other economic incentives
917 - Explicit trade in flexibility in demand and/or supply
918 - Direct control of demand and/or supply
919
920 Although analyzed in combination in the flexibility use case, distinguishing between these
921 approaches allows for better analysis in relation to the European electricity market. Below, each of
922 these approaches is analyzed further in relationship to the organizational structure of the European
923 electricity market.
924
925 The figures used throughout the analysis below show roles and their associations from the
926 European harmonized electricity market role model and how they relate to actors and their
927 associations from the use case. This is graphically represented according to the legend as shown
928 in Figure 47.
929
Legend:

Association Association
Role Actor
Harmonized Electricity Market Role Model use case
930
931 Figure 47: Legend used in analysis of relation between the flexibility operator actor and the
932 European harmonized electricity market role model

933 C.4.1 Communication of price signals, tariffs and other economic incentives
934 Economic incentives can be given to parties connected to the grid, primarily based on state of the
935 grid or market. Within [ENTSO-E 2011], parties connected to the grid are ‗associated‘ to the market
936 through the Balance Supplier role and connect to grid operations through the Grid Access Provider
937 role. Figure 48 provides a visualization of this mapping.
938
(providing grid (providing market
based incentives) based incentives)
Grid Access Provider Party connected Balance Supplier
◄ is contracted with to the Grid has a balance delivery
contract with ►
«use case actor» «use case actor» «use case actor»
Flexibility Operator provides economic Smart Customer ◄ provides economic Flexibility Operator
incentives to ► incentives to

uses ▼

Accounting Point
provides access to the grid through ► ◄ supplies to / takes from
939
940 Figure 48: Economic incentives in the flexibility use cases in relation to European electricity
941 market

100
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

942 C.4.2 Explicit trade in flexibility in demand and/or supply

943 The explicit trade in flexibility is closely related to the mapping of the use case wherein the
944 Flexibility Operator performs direct control; with the major differences that the ‗smart customer‘
945 moves in the value chain in the sense that it now takes the Resource Provider role itself instead of
946 the Flexibility Operator. This mapping is visualized in Figure 49.
947
Party connected to Resource Provider cautioned by ► Balance Responsible
the Grid Party

«use case actor» ◄ buys flexibility from «use case actor»

Smart Customer Flexibility Operator

948 (explicitly trading flexibility)

949 Figure 49: Explicit trade in flexibility in relation to European electricity market

950 C.4.3 Direct control of demand and/or supply

951 Within [ENTSO-E 2011] the role of Resource Provider is identified, actors with this role take part in
952 system operations by providing reserve (balancing) services, by up/down regulation of ‗resource
953 (or reserve) objects‘ under its control. In case of direct control, the Flexibility Operator can be
954 considered performing the Resource Provider role. The mapping of this use case to the roles of
955 [ENTSO-E 2011] is visualized in Figure 50.
956
(using direct control)

Party connected Resource Provider

to the Grid
◄ manages cautioned by ► Balance
«use case actor» equipment of «use case actor» Responsible Party
Smart Customer Flexibility Operator

manages ▼

Resource Object
957
958 Figure 50: Direct control of demand and/or supply use case
959 in relation to European electricity market

960 Note: the relationship between Party connected to the Grid and Resource Provider is not defined in
961 [ENTSO-E 2011]. The relationship between Resource Object (a domain from [ENTSO 2012], not to
962 be mistaken with the organizational domains of the European conceptual model) and the Party
963 connected to the Grid is assumed.
964
965 Note: the Flexibility Operator in its role of Resource Provider connects to power system
966 management and the market via another party (or by itself) performing the Balance Responsible
967 Party role.
968

101
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Annex D
Functional Architecture
969 This section will be filled if applicable or necessary.

102
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Annex E
Information Architecture
970 Within the SGAM, one particular aspects of the layer is the level of data exchanged between the
971 various layers. The particular focus of the layer within the SGAM is the meaningful representation
972 and localization of the data models, abstract communication system interfaces towards the
973 communication layer and the functional (system) layers implementing the logics and the smart grid
974 component using standards and data models.
975
976 The Information layer is intended to show data models that are used by the sub-functions in order
977 to fulfill the use case. Within section 5 of this document, the SGAM use case has already outlined
978 the application of the mapping as depicted in the next graphic.
979

Market

CRM
Computer
Enterprise

Gateway CIM DMS

IEC 61968-4
Computer

Operation
HMI HES
420
IEC 61850-7-4

Station
850-7-

Data
Concentrator
IEC 61

HAN Field
DER Controller
RTU Controller

G H
Process

HV MV LV

Generation Transmission Distribution DER Customer Premise

980
981 In addition to the standards already used and depicted, the JWG report form CEN/CENELEC and
982 ETSI 3 and its annex 6 have already outlined the needed data model standards which will also be

3 JWG report on standards for smart grids, version 1.0

103
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

983 evaluated from the view of the first set of standards group. Harmonization on the view of data
984 integration technology vs. system/sub-system taxonomy of FSS 2.0 report is envisioned for version
985 3 of this SG-CG/RA report.
986
987 For this version of the report, relevant data models already identified are the following ones which
988 will be mapped onto the SGAM domain/zones plane (note: subject to further extension):
989
990 Mapping of IEC 61850 Common Data Classes on IEC 60870-5-104 (IEC 61850-80-1 TS)
991 OASIS EMIX
992 UN/CEFACT CCTS
993 EN 60870-6-802:2002 + A1:2005, Telecontrol equipment and systems – Part 6-802:
994 Telecontrol protocols compatible with ISO standards and ITU-T recommendations –
995 TASE.2 Object models
996 EN 60870-5-1:1993, Telecontrol equipment and systems – Part 5: Transmission protocols –
997 Section 1: Transmission frame formats
998 EN 60870-5-3:1992, Telecontrol equipment and systems – Part 5: Transmission protocols –
999 Section 3: General structure of application data
1000 IEC 61850-7-410 Ed. 1.0, Communication networks and systems for power utility
1001 automation – Part 7-410: Hydroelectric power plants – Communication for monitoring and
1002 control
1003 IEC 61850-7-420, Communication networks and systems for power utility automation – Part
1004 7-420: Basic communication structure – Distributed energy resources logical nodes
1005 IEC 61400-25-2, Communications for monitoring and control of wind power plants – Part
1006 25-2: Information models
1007 IEC 61400-25-3, Communications for monitoring and control of wind power plants – Part
1008 25-3: Information exchange models
1009 IEC 61400-25-6, Communications for monitoring and control of wind power plants – Part
1010 25-6 Communications for monitoring and control of wind power plants: Logical node
1011 classes and data classes for condition monitoring
1012 IEC 62056 series, Electricity metering – Data exchange for meter reading, tariff and load
1013 control, Parts 21, 31, 41, 42, 46, 47, 51, 52, 53, 61, 62
1014 IEC 61334, Distribution automation using distribution line carrier systems – Part 4 Sections
1015 32, 511, 512, Part 5 Section 1
1016 EN 61970-301:2004, Energy management system application program interface (EMS-API)
1017 – Part 301: Common information model (CIM) base
1018 EN 61970-402:2008 Ed. 1.0, Energy management system application program interface
1019 (EMS- API) – Part 402: Component interface specification (CIS) – Common services
1020 EN 61970-403:2007, Energy management system application interface (EMS- API) – Part
1021 403: Component Interface Specification (CIS) – Generic Data Access
1022 EN 61970-404:2007, Energy management system application program interface (EMS-API)
1023 – Part 404: High Speed Data Access (HSDA))
1024 EN 61970-405:2007, Energy management system application program interface (EMS-API)
1025 – Part 405: Generic eventing and subscription (GES)
1026 EN 61970-407:2007, Energy management system application program interface (EMS-API)
1027 – Part 407: Time series data access (TSDA)
1028 EN 61970-453:2008, Energy management system application interface (EMS- API) – Part
1029 453: CIM based graphics exchange
1030 EN 61970-501:2006, Energy management system application interface (EMS- API) – Part
1031 501: Common information model resource description framework (CIM RDF) Schema
1032 EN 61968-:2004, Application integration at electric utilities – System interfaces for
1033 distribution management – Part 3: Interface for network operations
1034 EN 61968-4:2007, Application integration at electric utilities – System interfaces for
1035 distribution management – Part 4: Interfaces for records and asset management

104
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

1036 EN 61968-9:2009, System Interfaces For Distribution Management – Part 9: Interface

1037 Standard for Meter Reading and Control
1038 FprEN 61968-11:2010, System Interfaces for Distribution Management – Part 11:
1039 Distribution Information Exchange Model
1040 EN 61968-13:2008, System Interfaces for distribution management – CIM RDF Model
1041 Exchange Format for Distribution
1042 IEC 61850-5 Ed. 1.0, Communication networks and systems in substations – Part 5:
1043 Communication requirements for functions and device models
1044 IEC 61850-6 Ed. 1.0, Communication networks and systems in substations – Part 6:
1045 Configuration description language for communication in electrical substations related to
1046 IEDs
1047 IEC 61850-7-1 Ed. 1.0, Communication networks and systems in substations – Part 7-1:
1048 Basic communication structure for substation and feeder equipment – Principles and
1049 models
1050 IEC 61850-7-2 Ed. 1.0, Communication networks and systems in substations – Part 7-2:
1051 Basic communication structure for substation and feeder equipment – Abstract
1052 communication service interface (ACSI)
1053 IEC 61850-7-3 Ed. 1.0, Communication networks and systems in substations – Part 7-3:
1054 Basic communication structure for substation and feeder equipment – Common data
1055 classes
1056 IEC 61850-7-4 Ed. 1.0, Communication networks and systems in substations – Part 7-4:
1057 Basic communication structure for substation and feeder equipment – Compatible logical
1058 node classes and data classes
1059 IEC 62325-301 Ed.1.0 : Common Information Model Market Extensions
1060 IEC 62325-501 Framework for energy market communications - Part 501: General
1061 guidelines for use of ebXML
1062 IEC 62325-351 Framework for energy market communications - Part 351: CIM European
1063 Market Model Exchange Profile
1064 IEC 62325-502 Framework for energy market communications - Part 502: Profile of ebXML
1065

105
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Annex F
Communication Architecture
1066
1067 This section is provided as a separate document.
1068

106
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Annex G
Bibliography
1069
1070 The following references are made in the main body of the Report:
1071
1072 [Dänekas 2011] Christian Dänekas, Sebastian Rohjans, Carsten Wissing, Hans-Jürgen
1073 Appelrath: Future Energy Grid" - Migration Paths into the Internet of
1074 Energy, In: Proceedings of the eChallenges Conference (e-2011),
1075 [Jonkers 2010] TOGAF 9 and ArchiMate 1.0 White paper, The Open Group 2010
1076 [Uslar et al 2012] Mathias Uslar, Michael Specht, Sebastian Rohjans, Jörn Trefke, Jose M
1077 Gonzalez: The Common Information Model CIM: IEC 61970, 61968 and
1078 62325, Springer Heidelberg, 2012
1079
1080 The following references are made in Annex F:
1081 OPEN meter. Energy Project No 226369. Funded by EC
1082 Cenelec TC205 new working group WG18 Kick of Presentation 24.11.2011
1083

107
 CEN-CENELEC-ETSI Smart Grid Coordination Group

Date: 11/2012

Secretariat: CCMC

SG-CG/M490/C_Smart Grid Reference Architecture

Annex F
Communication Architecture
(Version 3.0)

1
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1 Contents

2 Table of contents
3
4 Content Page
5 Main changes in this version ......................................................................................................... 5
6 1 References ............................................................................................................................. 6
7 2 Symbols and abbreviations ................................................................................................ 10
8 3 Executive Summary ............................................................................................................. 13
9 3.1 Recommendations ............................................................................................................ 13
10 3.1.1 Recommendation 1....................................................................................................... 13
11 3.1.2 Recommendation 2....................................................................................................... 13
12 3.1.3 Recommendation 3....................................................................................................... 13
13 3.1.4 Recommendation 4....................................................................................................... 14
14 3.1.5 Recommendation 5....................................................................................................... 14
15 3.1.6 Recommendation 6....................................................................................................... 14
16 3.1.7 Recommendation 7....................................................................................................... 14
17 3.1.8 Recommendation 8....................................................................................................... 14
18 3.2 Smart Grid sub-networks ................................................................................................... 14
19 3.3 Applicability statement of the Communication Technologies to the Smart Grid Sub-
20 networks............................................................................................................................ 18
21 4 Communication Standards for the Smart Grid .................................................................. 20
22 4.1 Internet Protocol Technology............................................................................................. 20
23 4.1.1 The Key Advantages of Internet Protocol ...................................................................... 20
24 4.1.2 IP layered architecture .................................................................................................. 21
25 4.1.3 The Technical Components of IPv6 Smart Grid Infrastructure ...................................... 21
26 4.1.4 IPv6 Addressing............................................................................................................ 22
27 4.2 Field, Neighborhood, home / building area networks overview .......................................... 23
28 4.2.1 Introduction ................................................................................................................... 23
29 4.2.2 Power Line Technology ................................................................................................ 23
30 4.2.3 Mesh Network technologies .......................................................................................... 26
31 4.2.4 Physical and MAC layers .............................................................................................. 28
32 4.2.5 IPv6 adaptation layer .................................................................................................... 34
33 4.2.6 IP protocols layer 3 and above...................................................................................... 35
34 4.2.7 EN 50090 family (KNX) ................................................................................................. 36
35 4.2.8 EN 14908 family ........................................................................................................... 39
36 4.3 SCADA substation protocols ............................................................................................. 40
37 4.3.1 IEC 60870..................................................................................................................... 40
38 4.3.2 IEC 60870-5-101 System topology ............................................................................... 41
39 4.3.3 IEC 60870-5-101 Message structure ............................................................................ 41
40 4.3.4 IEC 60870-5-101 Addressing ........................................................................................ 42
41 4.3.5 IEC 60870-5-104 Networked version ............................................................................ 42
42 4.3.6 IEC 60870-4-101 Application data objects .................................................................... 43
43 4.4 Wireless Access & Wide Area Technologies ..................................................................... 43
44 4.4.1 Overview of GSM Family of Cellular Communication Systems ..................................... 43

2
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

45 4.4.2 GPRS / EDGE (General packet radio service / Enhanced Data rates for Global
46 Evolution ....................................................................................................................... 45
47 4.4.3 UMTS (Universal Mobile Telecommunications System) ................................................ 46
48 4.4.4 Long Term Evolution (LTE) for Smart grid..................................................................... 50
49 4.4.5 Wireline access technologies ........................................................................................ 54
50 4.5 Core and metro networks overview ................................................................................... 56
51 4.5.1 Introduction ................................................................................................................... 56
52 4.5.2 IP MPLS ....................................................................................................................... 56
53 4.5.3 MPLS-TP ...................................................................................................................... 56
54 4.5.4 OTN .............................................................................................................................. 58
55 4.5.5 Data services over SDH................................................................................................ 60
56 4.5.6 Mapping into SDH payloads.......................................................................................... 60
57 4.6 Higher level communication protocols ............................................................................... 61
58 4.6.1 RESTful Web Services ................................................................................................. 61
59 4.6.2 SOAP/RPC Web Services ............................................................................................ 62
60 4.6.3 Architectures, Protocols and languages for Web Services ............................................ 62
61 4.6.4 Performance considerations ......................................................................................... 64
62 5 Generic Use Cases and related Communication Architecture examples ........................ 66
63 5.1 Use cases ......................................................................................................................... 66
64 5.1.1 Demand Response ....................................................................................................... 66
65 5.1.2 Distribution Automation FLISR ...................................................................................... 88
66 5.1.3 Tele-protection using an IP/MPLS network ................................................................... 92
67 5.1.4 Workforce communication ............................................................................................ 96
68 5.2 Mapping Example Use Cases to the Conceptual Model .................................................... 97
69 5.3 QoS requirements for different Smart Grid Applications .................................................... 99
70 6 Description of selected communication profiles for the Smart Grid
71 communications ................................................................................................................ 100
72 6.1 Introduction ..................................................................................................................... 100
73 6.2 Profile Example 1: Field Area Network ............................................................................ 100
74 6.2.1 Communication profile name: Field Area Network ...................................................... 100
75 6.2.2 Communication requirements and boundaries ............................................................ 101
76 6.2.3 Scalability: .................................................................................................................. 101
77 6.2.4 Network diagram......................................................................................................... 101
78 6.2.5 List of systems if relevant ............................................................................................ 102
79 6.2.6 List of technologies ..................................................................................................... 102
80 6.2.7 Specifications / standards ........................................................................................... 103
81 6.2.8 Security considerations ............................................................................................... 103
82 6.2.9 Configuration parameters ........................................................................................... 103
83 6.2.10 MAC / PHY configuration parameters: .................................................................... 107
84 6.2.11 Best current practice: ............................................................................................. 107
85 6.3 Profile Example 2: IP MPLS ............................................................................................ 107
86 6.3.1 Introduction ................................................................................................................. 107
87 6.3.2 Communication requirements and boundaries ............................................................ 107
88 6.3.3 Detailed Network diagram for the profile ..................................................................... 108
89 6.4 Initial list of profiles for future development by SDOs ....................................................... 111
90 6.5 Interoperability consideration/recommendations .............................................................. 112
91 7 Communication architecture topologies for the Smart Grid........................................... 113
92 7.1 Subscriber Access Network ............................................................................................. 113
93 7.2 Neighborhood Network .................................................................................................... 113
94 7.3 Field Area Network .......................................................................................................... 113
95 7.4 Low-end intra-substation network .................................................................................... 113
96 7.5 Intra-substation network .................................................................................................. 113

3
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

97 7.6 Inter substation network .................................................................................................. 114

98 7.6.1 High voltage teleprotection network ............................................................................ 114
99 7.6.2 Medium voltage inter-substation network .................................................................... 114
100 7.6.3 MV Substation to substation communication topology: Point to Multipoint (P2MP)
101 using BPL ................................................................................................................... 115
102 7.6.4 MV Substation to substation communication topology: Point to Point (P2P) using
103 BPL............................................................................................................................. 116
104 7.7 Intra Control Centre / Intra Data centre Network .............................................................. 116
105 7.8 Enterprise Network .......................................................................................................... 117
106 7.9 Balancing Network .......................................................................................................... 117
107 7.10 Interchange Network ....................................................................................................... 117
108 7.11 Trans-Regional – Trans-National Network ....................................................................... 117
109 7.12 Wide and Metropolitan Area Network .............................................................................. 117
110 8 Security .............................................................................................................................. 118
111 Appendix A Industry Fora and Alliances References............................................................... 120
112 Appendix B Relationship to the SGAM model .......................................................................... 121
113
114
115 List of Figures
116
117 Figure 1: SGAM Framework Architecture ...................................................................................... 15
118 Figure 2: Mapping of communication networks on SGAM Communication Layer .......................... 17
119 Figure 3: IP standard protocol layers............................................................................................. 21
120 Figure 4: Example of PLC usage .................................................................................................. 24
121 Figure 5: WiMAX usage model...................................................................................................... 32
122 Figure 6: 6LoWPAN within IP protocol stack ................................................................................. 35
123 Figure 7: EN 50090 protocol stack ................................................................................................ 38
124 Figure 8: EN 50090 HBES Standards Landscape ......................................................................... 39
125 Figure 9: EN 14908 protocol stack ................................................................................................ 40
126 Figure 10: Evolution of 3GPP Family of Mobile Broadband Technologies ..................................... 44
127 Figure 11: GSMA family of technologies development to date ...................................................... 45
128 Figure 12: Privacy issues associated with smart metering ............................................................ 50
129 Figure 13: MPLS TP context ......................................................................................................... 58
130 Figure 14: OTN multiplexing ......................................................................................................... 59
131 Figure 15: ETSI M2M architecture framework ............................................................................... 64
132 Figure 16: Smart Home Communication Example architecture ..................................................... 69
133 Figure 17: Demand Response functional Architecture .................................................................. 70
134 Figure 18: Smart Home Communication Example architecture ..................................................... 79
135 Figure 19: FLISR (1) Example architecture ................................................................................... 90
136 Figure 20: FLISR (2) Example architecture ................................................................................... 91
137 Figure 21: FLISR Communication networks mapping to the SGAM model .................................... 91
138 Figure 22: Tele-protection Example architecture ........................................................................... 92
139 Figure 23: Tele-Protection Architecture example........................................................................... 94
140 Figure 24: Delay incurred by the telecommunication equipment and the IP/MPLS network .......... 95
141 Figure 25: Tele-Protection: Mapping of communication networks to the SGAM model .................. 96
142 Figure 26: Workforce management example architecture ............................................................. 96
143 Figure 27: Architecture for IP/MPLS based teleprotection ........................................................... 107
144 Figure 28: MPLS services ........................................................................................................... 108
145 Figure 29: Teleprotection using VPLS (Ethernet TPRs) .............................................................. 109
146 Figure 30: Teleprotection using VPWS (TDM TPR) .................................................................... 109
147 Figure 31: Achieving protection for Teleprotection services. ....................................................... 110
148 Figure 32: Substation communication architecture example ....................................................... 114

4
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

149 Figure 33: Distribution grid: typical substation topology for European markets (Source Kema) ... 115
150 Figure 34: MV communication using MV BPL model, Point to multipoint topology ...................... 116
151 Figure 35: MV communication using MV BPL model, Point to point topology .............................. 116
152
153
154 List of Tables
155
156 Table 1: Applicability statement of the communication technologies to the smart grid sub-
157 networks ..................................................................................................................... 19
158 Table 2: Relevant Narrowband PLC Standards ............................................................................. 25
159 Table 3: Relevant Broadband PLC Standards............................................................................... 26
160 Table 4: Protocol Stack IEC 60870-5-104 ..................................................................................... 43
161 Table 5: Information Object Type Groups ..................................................................................... 43
162 Table 6: FLISR communication requirements ............................................................................... 89
163 Table 8: Tele-Protection communication requirements ................................................................. 93
164 Table 9: Mapping Example use Cases to the Conceptual Model Domains .................................... 97
165
166
167 History of document
168
Number Date Content
v0.5 24/01/2012 First TR external version for SG-CG “Sanity Check”
v1.0 02/03/2012 First Interim TR draft for official comments
v2.0 31/07/2012 Second interim TR draft for official comments
v3.0 15/11/2012 Final TR Annex E for adoption by M/490
169
170
171 Main changes in this version
172 The document has been deeply changed, in particular with an entirely new structure.
173
174 It has also a new Annex number, due to the changes to the main part of the Reference
175 Architecture 3.0 Report.
176
177

5
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

178 1 References
179
180 It should be noted that the SG-CG First Set of Standards Work Group report [SG-CG/B] provides a
181 list of references that may include most of the references below. In case of doubt on the applicable
182 referenced documents, the [SG-CG/B] list prevails.
183
184 References
185 [1] OPEN meter. Energy Project No 226369. Funded by EC
186 [7] CENELEC TC205 new working group WG18 Kick of Presentation 24.11.2011
187 [57] IEEE ISPLC2007 - Standards & Regulations Framework for LV-MV-HV Powerline
188 Communication Systems – Pisa, 2007 ITALY.
189 [60] IEC TC57 – Working Group 20 works.
190 [61] CLC SC205A – Working Groups 9 and 10 works.
191 [62] CIRED – Communication Requirements for Smart Grids – Frankfurt, June 2011,
192 GERMANY
193 [63] ADDRESS EC FP7 Project – http://portal.addressfp7.org/
194 [66] A Standardized and Flexible IPv6 Architecture for Field Area Networks

195 [67] Cisco Gridblocks architecture for Smart Grid

196
197 List of standards
198 [1] ISO/IEC 7498-1:1994; Information Technology – Open Systems Interconnect – Basic
199 Reference Model: The Basic Model
200 [2] ITU-T I.322 (02/99); Generic protocol reference model for telecommunication networks
201 [3] IETF RFC5654 Requirements of an MPLS Transport Profile
202 [4] IETF RFC5921 A Framework for PLS in Transport Networks
203 [5] CEN/CENELEC/ETSI JWG report on standards for smart grids – V1.0
204 [6] CEN/CENELEC/ETSI First set of standards – V1.0
205 [8] IETF RFC 6272: Internet Protocols for the Smart Grid. http://www.rfc-
206 editor.org/rfc/rfc6272.txt
207 [9] IETF RFC 5086: Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation
208 Service over Packet Switched Network (CESoPSN)
209 [10] IETF RFC4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet
210 (SAToP)
211 [11] IEEE P1901.2 Standard for Low Frequency (less than 500 kHz) Narrow Band Power Line
212 Communications for Smart Grid Applications
213 [12] IEEE 802.11: a list of standards is available under this link
214 http://standards.ieee.org/about/get/802/802.11.html
215 [13] IEEE 802.3: a list of standards is available under this link
216 http://standards.ieee.org/about/get/802/802.3.html
217 [14] IEEE 802.16: a list of standards is available under this link
218 http://standards.ieee.org/about/get/802/802.16.html
219 [15] IEEE 802.15.4: a list of standards is available under this link
220 http://web.archive.org/web/20080224053532/http://shop.ieee.org/ieeestore/Product.aspx?
221 product_no=SS95552
222 [16] ETSI 102 887
223  Electrocompatibility and radio spectrum Matters (ERM); Short Range Devices; Smart
224 Metering Wireless Access Protocol (SMEP). Part 1; PHY Layer
225  Electrocompatibility and radio spectrum Matters (ERM); Short Range Devices; Smart
226 Metering Wireless Access Protocol (SMEP). Part 2; MAC Layer
227 [17] RFC 4919: IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
228 Overview, Assumptions, Problem Statement, and Goals

6
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

229 [18] IETF roll: a list of Internet RFC is available under: http://tools.ietf.org/wg/roll/
230  IETF RFC 6550: RPL IPv6 Routing Protocol for Low-Power and Lossy Network
231  IETF RFC 6551: ROLL routing metrics
232  IETF RFC 6552: ROLL objective Function Zero
233  IETF RFC 6206: ROLL Trickle
234  draft-ietf-roll-minrank-hysteresis-of -11 2012-06-30 RFC Ed Queue
235  draft-ietf-roll-security-framework
236  draft-ietf-roll-p2p-measurement
237  draft-ietf-roll-p2p-rpl
238  draft-ietf-roll-trickle-mcast
239 [19] EN 50090:
240  EN 50090-2-1:1994 : System overview-Architecture
241  EN 50090-3-1:1994 : Aspects of application-Introduction to the application structure
242  EN 50090-3-2:1995 : Aspects of application-User process
243  EN 50090-3-2:2004 : Aspects of application-User process for HBES Class 1
244  EN 50090-4-1:2004 : Media independent layers-Application layer for HBES Class 1
245  EN 50090-4-2:2004 : Media independent layers–Transport layer, network layer and
246 general parts of datalink layer for HBES Class 1
247  EN 50090-5-1:2005 : Media and media dependent layers-Power line for HBES Class 1
248  EN 50090-5-2:2004 : Media and media dependent layers-Network based on HBES
249 Class1, TwistedPair
250  EN 50090-7-1:2004 : System management-Management procedures
251
252 [20] LTE3GPP TS 36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
253 Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2
254 http://www.3gpp.org/ftp/Specs/html-info/36300.htm
255  TS 36.201 Evolved Universal Terrestrial Radio Access (E-UTRA); LTE physical layer;
256 General description.
257  TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels
258 and modulation.
259  TS 36.212 Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and
260 channel coding.
261  TS 36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer
262 procedures.
263  TS 36.214 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer;
264 Measurements.
265  TS 36.216 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer for
266 relaying operation
267  3GPP TS 23.401 General Packet Radio Service (GPRS) enhancements for Evolved
268 Universal Terrestrial Radio Access Network (E-UTRAN) access
269  3GPP TS 22.368 Service requirements for Machine-Type Communications (MTC);
270 Stage 1
271  TR 23.888 System improvements for Machine-Type Communications (MTC)Service
272 requirements for Machine-Type Communications (MTC);
273  3GPP TS 23.682 Architecture Enhancements to facilitate communications with Packet
274 Data Networks and Applications
275  3GPP TS 24.312. Access Network Discovery and Selection Function (ANDSF)
276 Management Object (MO)
277  3GPP TS 23.402 Architecture Enhancements for Non-3GPP Accesses (Release 10)
278 [21] G.991.1 High bit rate digital subscriber line (HDSL) transceivers
279 [22] G.991.2 Single-pair high-speed digital subscriber line (SHDSL) transceivers
280 [23] G.992.1 Asymmetric digital subscriber line (ADSL) transceivers

7
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

281 [24] G.992.2 Splitterless asymmetric digital subscriber line (ADSL) transceivers
282 [25] G.992.3
283 [26] G.992.4 Splitterless asymmetric digital subscriber line transceivers 2 (splitterless ADSL2)
284 [27] G.993.1 Very high speed digital subscriber line transceivers (VDSL)
285 [28] G.993.2 Very high speed digital subscriber line transceivers 2 (VDSL2)
286 [29] G.993.5 Self-FEXT cancellation (vectoring) for use with VDSL2 transceivers
287 [30] G.994.1 Handshake procedures for digital subscriber line (DSL) transceivers
288 [31] G.995.1 Overview of digital subscriber line (DSL) Recommendations
289 [32] G.996.1 Test procedures for digital subscriber line (DSL) transceivers
290 [33] G.996.2 Single-ended line testing for digital subscriber lines (DSL)
291 [34] G.997.1 Physical layer management for digital subscriber line (DSL) transceivers
292 [35] G.998.1 ATM-based multi-pair bonding
293 [36] G.998.2 Ethernet-based multi-pair bonding
294 [37] G.998.3 Multi-pair bonding using time-division inverse multiplexing
295 [38] G.999.1 Interface between the link layer and the physical layer for digital subscriber line
296 (DSL) transceivers
297 [39] G.998.4 Improved Impulse Noise Protection (INP) for DSL Transceivers
298 [40] G.983.1: Broadband optical access systems based on Passive Optical Networks (PON)
299 [41] G.983.2: ONT management and control interface specification for B-PON
300 [42] G.983.3: A broadband optical access system with increased service capability by
301 wavelength allocation
302 [43] G.983.4: A broadband optical access system with increased service capability using
303 dynamic bandwidth assignment
304 [44] G.983.5: A broadband optical access system with enhanced survivability
305 [45] G.984.1: Gigabit-capable passive optical networks (GPON): General characteristics
306 [46] G.984.2: Gigabit-capable Passive Optical Networks (G-PON): Physical Media Dependent
307 (PMD) layer specification
308 [47] G.984.3: Gigabit-capable Passive Optical Networks (G-PON): Transmission convergence
309 layer specification
310 [48] G.984.4: Gigabit-capable passive optical networks (G-PON): ONT management and
311 control interface specification
312 [49] G.984.5: Gigabit-capable Passive Optical Networks (G-PON): Enhancement band
313 [50] G.984.6: Gigabit-capable passive optical networks (GPON): Reach extension
314 [51] G.984.7: Gigabit-capable passive optical networks (GPON): Long reach
315 [52] G.987.1: 10-Gigabit-capable passive optical networks (XG-PON): General requirements
316 [53] G.987.2: 10-Gigabit-capable passive optical networks (XG-PON): Physical media
317 dependent (PMD) layer specification
318 [54] G.987.3: 10-Gigabit-capable passive optical networks (XG-PON): Transmission
319 convergence (TC) layer specification
320 [55] G.709: Interfaces for the Optical Transport Network (OTN)
321
322 [56] IETF RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels,
323 http://www.ietf.org/rfc/rfc4090.txt
324
325
326 [58] IEC 62488-1 (Formerly EN60663) - Part 1: Planning of analogue and digital power line
327 carrier systems operating over EHV/HV/MV electricity grids.
328
329 [59] IEC 61334-4-1 - Distribution automation using distribution line carrier systems - Part 4:
330 Mains. Data communication protocols - Section 1: Reference model of the communication
331 system.
332 [68] G.707 : Network node interface for the synchronous digital hierarchy (SDH)
333 [69] G.7042: Link capacity adjustment scheme for virtual concatenated signals.

8
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

334 [70] G.7041: Generic Framing Procedure (GFP)

335 [71] G.803: Architecture of transport networks based on the synchronous digital hierarchy
336 (SDH)
337 [72] G.783: Characteristics of synchronous digital hierarchy (SDH) equipment functional blocks
338
339
340 [73] ISO/IEC 14908:
341  ISO/IEC 14908-1: Control network protocol stack
342  ISO/IEC 14908-2: Twisted-pair channel for networked control systems
343  ISO/IEC 14908-3: Power Line channel in the EN 50065-1 CENELEC C-Band
344  ISO/IEC 14908-4: Transporting over Internet Protocol (IP) networks
345  ETSI TS 103 908: Power Line channel in the EN 50065-1 CENELEC A-Band
346 [74] ITU- T G 9955 / 56 Narrow-band OFDM power line communication transceivers
347 [75] W3C REC-xml-20001006, Extensible Markup Language (XML) 1.0
348 [76] W3C WD-ws-arch-20021114, Web Services Architecture
349 [77] W3C REC-xml-names, Name spaces in XML
350 [78] IETF RFC 2616Hypertext Transfer Protocol -- HTTP/1.1
351 [79] W3C RECsoap12-part1-20070427, SOAP Version 1.2 Part 1: Messaging Framework
352 [80] W3C REC-soap12-part2-20070427, SOAP Version 1.2 Part 2: Adjuncts, Section 7: SOAP
353 HTTP Binding,
354 [81] OASIS, wsdd-soapoverudp-1.1-spec-pr-01, OASIS Standard, SOAP-over-UDP
355 [82] IETF RFC 5246The Transport Layer Security (TLS) Protocol, Version 1.2
356 [83] W3C REC-ws-addrcore-20060509, Web Services Addressing 1.0
357 [84] W3C RECws-addr-soap-20060509, Web Services Addressing 1.0 - SOAP Binding
358 [85] OASIS, wsdd-discovery-1.1-spec-os, Web Services Dynamic Discovery (WS-Discovery)
359 [86] W3C, SUBM-WSEventing-20060315, Web Services Eventing (WS-Eventing)
360 [87] W3C, NOTEwsdl-20010315, Web Services Description Language (WSDL) 1.1,
361 [88] W3C, SUBM-wsdl11soap12-20060405, WSDL 1.1 Binding Extension for SOAP 1.2
362 [89] ETSI, TS 102690 Machine-to-Machine communications (M2M); Functional architecture
363 [90] ETSI, TS 102921 Machine-to-Machine communications (M2M); mIa, dIa and mId
364 interfaces
365 [91] IETF RFC 6120Extensible Messaging and Presence Protocol (XMPP): Core
366 [92] IETF RFC 6121Extensible Messaging and Presence Protocol : Instant Messaging and
367 Presence
368 [93] IETF RFC 6122Extensible Messaging and Presence Protocol : Address Format
369 [94] IETF RFC 3031Multiprotocol Label Switching Architecture
370 [95] IETF RFC 3032MPLS Label Stack Encoding
371 [96] IETF RFC 791 Internet Protocol
372 [97] IETF RFC 2460Internet Protocol, Version 6 (IPv6) Specification
373 [98] ITU-T G.991.1 High bit rate digital subscriber line (HDSL) transceivers
374 [99] ITU-T G.798 Characteristics of optical transport network hierarchy equipment functional
375 blocks
376 [100] ITU-T G.781 Synchronization layer functions
377 [101] ITU-T G.872 Architecture of optical transport networks
378 [102] IETF RFC 6178Label Edge Router Forwarding of IPv4 Option Packets
379 [103] ITU-T G.783 Characteristics of synchronous digital hierarchy (SDH) equipment
380 functional blocks
381 [104] ITU-T G.798 Characteristics of optical transport network hierarchy equipment functional
382 blocks
383 [105] ITU-T G.803 Architecture of transport networks based on the synchronous digital
384 hierarchy (SDH)
385 [106] IEEE 802.1: a list of standards is available under this link
386 http://standards.ieee.org/about/get/802/802.1.html

9
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

387

388 2 Symbols and abbreviations

389
390 Acronyms
391 3GPP 3rd Generation Partnership Project
392 6LoWPAN IPv6 over Low power Wireless Personal Area Networks
393 ADSL Asymmetric digital subscriber line
394 AES Advanced Encryption Standard
395 ANSI American National Standard Institute
396 ASHRAE American Society of Heating, Refrigerating and Air-Conditioning
397 ASK Amplitude Shift Keying
398 ATM Asynchronous Transfer Mode,
399 B-PON Broadband PON
400 BPL Broadband Power Line
401 BPSK Binary Phase Shift Keying
402 CCM Cloud Controls Matrix
403 CEMS Customer Energy Management Systems
404 CEN Comité Européen de Normalisation.
405 CENELEC Comité Européen de Normalisation Electrotechnique
406 CO Central Office
407 CSMA-CA Carrier Sense Multiple Access with Collision Avoidance
408 DA Distribution Automation
409 DLMS/COSEM Device Language Message Specification / Companion Specification for Energy
410 Metering
411 DNP Distributed Network Protocol
412 DODAG Destination Oriented Directed Acyclic Graph
413 DRMS Demand Response Management System
414 DSL Digital Subscriber Line
415 DSSS Direct Sequence Spread Spectrum
416 DWDM Dense Wavelength-division multiplexing
417 E-UTRAN Evolved UTRAN
418 EIRP Equivalent Isotropically Radiated Power
419 ENC-MAC Encrypted Message Authentication Code
420 ENODEB Evolved Node B
421 ETSI European Telecommunications Standard Institute
422 ETX Expected Transmission
423 FAN Field Area Network
424 FCC Federal Communication Commission
425 FDD Frequency-Division Duplexing
426 FLISR Fault Location and Service Recovery
427 FR Frame Relay
428 FTTB Fiber To The Building (Business)
429 FTTC Fiber To The Cabinet
430 FTTH Fiber-to-the-Home
431 G-PON Gigabit capable Passive Optical Networks.
432 GMPLS Generalized Multi-Protocol Label Switching
433 GOOSE Generic Object Oriented Substation Events
434 GPRS General Packet Radio Service
435 GSM Global System for Mobile
436 H2H Human to Human
437 HAN Home Area Network
438 HBES Home and Building Electronic Systems

10
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

439 HDSL High-bit-rate digital subscriber line

440 HeNB Home eNodeB
441 HIPERMAN HIgh PErformance Radio Metropolitan Area Network
442 HSPA High Speed Packet Access
443 HV High Voltage
444 IED Intelligent Electronic Device
445 IEEE Institute of Electrical and Electronics Engineers
446 IETF Internet Engineering Task Force
447 IP Internet Protocol
448 IPTV Internet Protocol Television
449 IPV4 Internet Protocol Version 4
450 IPv6 Internet Protocol Version 6
451 ISM Industrial Scientific and Medical (frequency band)
452 ISO International Organization for Standardization
453 ITU-T International Telecommunications Union for the Telecommunication
454 Standardization Sector
455 KNX EN 50090 (was Konnex)
456 L2TP Layer 2 Tunnelling Protocol
457 LF NB Low Frequency Narrow Band
458 LLN Low power and Lossy Networks
459 LNAP Local Network Access Point
460 LON local operation network
461 LR WPAN Low Rate Wireless Personal Area Network
462 LSP Label Switched Path
463 LTE Long Term Evolution
464 LV Low Voltage
465 MAC Media Access Control
466 MIMO Multiple Input Multiple Output
467 MPLS Multiprotocol Label Switching
468 MPLS-TP MPLS Transport Profile
469 MV Medium Voltage
470 NAN Neighborhood Area Network
471 NNAP Neighborhood Network Access Point
472 O-QPSK Offset Quadrature Phase Shift Keying
473 O&M Operation and Maintenance
474 OAM Operations, Administration, and Maintenance
475 OFDM Orthogonal Frequency Division Multiplexing
476 OFDMA Orthogonal Frequency-Division Multiple Access
477 OLT Optical Line Termination
478 ONU Optical Network Unit
479 OPEX Operation Expenditure
480 OSI Open System Interconnection
481 OSS Operations support system
482 OTN Optical Transport Network
483 P2P Point To Point
484 PAN Personal Area Network
485 PBR Performance Based Rates
486 PDH Plesiochronous Digital Hierarchy
487 PEV Plug in Electric Vehicle
488 PHP Penultimate Hop Popping
489 PLC Power Line Carrier
490 PLC Programmable Logic Controller
491 PON Passive Optical Network

11
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

492 PSN Packet Switched Network

493 QoS Quality Of Service
494 RF Radio Frequency
495 RFC Request for Comments
496 RPL Routing Protocol for Low power and lossy networks (LLN)
497 SAIDI System Average Interruption Duration Index
498 SC-FDMA Single Carrier Frequency Division Multiple Access
499 SCADA Supervisory control and data acquisition
500 SDH Synchronous Digital Hierarchy
501 SHDSL Single-pair high-speed digital subscriber line
502 SON Self Organizing Network
503 SONET Synchronous Optical Networking
504 SRD Short Range Device
505 TDD Time-Division Duplexing
506 TDM Time-Division Multiplexing
507 TPR Tele-Protection Relay
508 TTI Transmission Time Interval
509 UE User Equipment
510 UMTS Universal Mobile Telecommunications System
511 VDSL Very-high-bit-rate digital subscriber line
512 WAN Wide Area Network
513 WASA Wide Area Situation Awareness
514 WLAN Wireless Local Area Network
515 WMAN Wireless Metropolitan Area Network
516 WPA Wi-Fi Protected Access
517 WPA2 Wi-Fi Protected Access version II
518 WPAN Wireless Personal Area Network
519 XG-PON 10G PON
520 xDSL Digital Subscriber Line
521
522

12
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

523 3 Executive Summary

524
525 This document deals with communication aspects of the Smart Grid. The main objective of the
526 study performed by the RAWG on Smart Grid communications is to identify gaps that need to be
527 addressed in standardization organisations. This work considered generic Smart Grid use cases to
528 derive the requirements and to consider the adequacy of those requirements to the existing
529 communications standards in order to identify communication standards gaps. RAWG found that
530 there are no specific standardisation gaps for Layer 1 to Layer 4 standards (according to OSI
531 model) mandating the immediate need for evolution of existing standards. However, there is an
532 immediate need to develop profiling and interoperability specifications based on the existing
533 communications standards. The profiling work is the task of the SDOs, however for the purpose of
534 explaining our vision of such profiling, a draft profile is proposed in this document for an example1
535 Smart Grid sub-network architecture.
536
537 The remaining of this document is organised as follows
538  Clause 1 continues to provide a set of recommendations for standardisation work as well
539 as a mapping of the communication technologies to Smart Grid communication sub-
540 networks
541  Clause 2 provides an overview of the Communication standards that are applicable for
542 Smart Grid communications
543  Clause 3 provides a description of generic Smart Grid use cases, their communication
544 requirements, along with recommendations on how to setup the communication networks
545 to address these requirements
546  Clause 4 provides an example profile and develops interoperability considerations

547 3.1 Recommendations

548 3.1.1 Recommendation 1

549 RAWG has examined the communication needs of different Smart Grid use cases. There are
550 cases that have very stringent communications requirements (PMU, Tele-protection, etc.),
551 however we believe all these requirements can be addressed using existing communications
552 standards with sufficient engineering guidelines (see R2). There is already a large set of
553 communication standards for each network segment identified. RAWG did not identify any gaps
554 mandating the need for new communication standards.

555 3.1.2 Recommendation 2

556 Communication network performance including QoS, reliability, and security must be managed so
557 to achieve the smart grid communications requirements. This mandates the need to develop
558 communication profiles on “how to use” the current communication standards for Smart Grids. IEC
559 in collaboration with bodies such as IETF, IEEE, ETSI, CEN and CENELEC is the right place to
560 develop such profiles. A profile is defined to be a description of how to use the different options
561 and capabilities within a set of standards for a particular use.

562 3.1.3 Recommendation 3

563 There is a need to develop a standardised Service Level Specification (i.e. the technical part of a
564 Service Level Agreement: availability, resiliency, DoS, etc.) that allows a utility network or
565 application to rely on predictable network performance when communication is provided by a
566 shared communication infrastructure.

1 RAWG may develop more than one profile

13
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

567 3.1.4 Recommendation 4

568 Deployment constraints mandate the need for both wireline and wireless communications. Utility
569 access to wireless network resources is necessary. Where spectrum is allocated for use by utility
570 networks, this will help progress the Smart Grid deployments ensuring the standard work and
571 products take into account the allocated spectrum for utilities.

572 3.1.5 Recommendation 5

573 Given the plethora of L1 and L2 technologies (according to OSI) used in the different
574 communication standards (as well as the upcoming ones), IP shall be the recommended L3
575 technology to ensure communications are future proof and avoid the unnecessary need for
576 interworking gateways in different parts of the Smart Grid communication networks.

577 3.1.6 Recommendation 6

578 This document provides a list of applicable communication technologies as well as their
579 applicability statement to different sub-networks of the communications architecture. The choice of
580 a technology for a sub-network is left to implementations, which need to take into account a variety
581 of deployment constraints.

582 3.1.7 Recommendation 7

583 Profiles (see Recommendation 2) should be used as a basis for building interoperability test
584 specifications. When interoperability test specifications / suites exist, those should be leveraged for
585 building test specifications for the communication profiles.

586 3.1.8 Recommendation 8

587 ESOs should consider the approval of their specifications applicable to Smart Grid as ENs.
588
589 Recognizing the role of consortia in providing & developing specifications for communications and
590 considering the fact that these consortia adopt an open standards approach (i.e. IEEE, IETF,
591 W3C) the European Commission should endorse the importance of their specifications in building
592 communications network, including for Smart Grid. There are globally recognized technologies &
593 deployments for communications that use a selection of open specifications from ESOs, global
594 SDOs and these consortia. The endorsement of the specifications into ENs, may not be
595 reasonable in defined timeframe or achievable.

596 3.2 Smart Grid sub-networks

597 We are identifying the different networks that play a role in the overall communication architecture
598 and we are representing their scope using the SGAM model (figure 1, below).

14
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Business Objectives
Polit. / Regulat.. Framework

Business Layer

Function Layer
Outline of Usecase
Functions

Interoperability Information Layer

Data Model
Layers Data Model

Communication Layer
Protocol Market
Protocol
Enterprise

Component Layer Operation

Station
Generation Zones
Transmission Field
Distribution
Process
DER
Domains Customer
Premises
599
600 Figure 1: SGAM Framework Architecture
601 The following networks could be defined, see figure 3-2 below where these terms are used:
602
603 • (A) Subscriber Access Network
604 Networks that provide general broadband access (including but not limited to the internet)
605 for the customer premises (homes, building, facilities). They are usually not part of the
606 utility infrastructure and provided by communication service providers, but can be used to
607 provide communication service for Smart Grid systems covering the customer premises
608 like Smart Metering and Aggregated prosumers management.
609
610 • (B) Neighborhood network
611 Networks at the distribution level between distribution substations and end users. It is
612 composed of any number of purpose-built networks that operate at what is often viewed as
613 the “last mile” or Neighborhood Network level. These networks may service metering,
614 distribution automation, and public infrastructure for electric vehicle charging, for example.
615
616 • (C) Field Area Network
617 Networks at the distribution level upper tier, which is a multi-services tier that integrates the
618 various sub layer networks and provides backhaul connectivity in two ways: directly back to
619 control centres via the WAN (defined below) or directly to primary substations to facilitate
620 substation level distributed intelligence. It also provides peer-to-peer connectivity or hub
621 and spoke connectivity for distributed intelligence in the distribution level.
622
623 • (D) Low-end intra-substation network

15
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

624 Networks inside secondary substations or MV/LV transformer station. It usually connects
625 RTUs, circuit breakers and different power quality sensors.
626
627 • (E) Intra-substation network
628 Network inside a primary distribution substation or inside a transmission substation. It is
629 involved in low latency critical functions such as tele-protection. Internally to the substation,
630 the networks may comprise from one to three buses (system bus, process bus, and multi-
631 services bus).
632
633 • (F) Inter substation network
634 Networks that interconnect substations with each other and with control centres. These
635 networks are wide area networks and the high end performance requirements for them can
636 be stringent in terms of latency and burst response. In addition, these networks require very
637 flexible scalability and due to geographic challenges they can require mixed physical media
638 and multiple aggregation topologies. System control tier networks provide networking for
639 SCADA, SIPS, event messaging, and remote asset monitoring telemetry traffic, as well as
640 peer-to-peer connectivity for tele-protection and substation-level distributed intelligence.
641
642 • (G) Intra-Control Centre / Intra-Data Centre network
643 Networks inside two different types of facilities in the utility: utility data centres and utility
644 control centres. They are at the same logical tier level, but they are not the same networks,
645 as control centres have very different requirements for connection to real time systems and
646 for security, as compared to enterprise data centres, which do not connect to real time
647 systems. Each type provides connectivity for systems inside the facility and connections to
648 external networks, such as system control and utility tier networks.
649
650 • (H) Enterprise Network
651 Enterprise or campus networks, as well as inter-control centre networks. Since utilities
652 typically have multiple control centres and multiple campuses that are widely separated
653 geographically.
654
655 • (I) Balancing Network
656 Networks that interconnect generation operators and independent power producers with
657 balancing authorities, and networks those interconnect balancing authorities with each
658 other. In some emerging cases, balancing authorities may also dispatch retail level
659 distributed energy resources or responsive load.
660
661 • (J) Interchange network
662 Networks that interconnect regional reliability coordinators with operators such as
663 transmission operators and power producers, as well as networks that connect wholesale
664 electricity markets to market operators, providers, retailers, and traders. In some cases, the
665 bulk markets are being opened up to small consumers, so that they have a retail-like
666 aspect that impacts networking for the involved entities.
667
668 • (K) Trans-Regional / Trans-National network
669 Networks that interconnect synchronous grids for power interchange, as well as emerging
670 national or even continental scale networks for grid monitoring, inter-tie power flow
671 management, and national or continental scale renewable energy markets. Such networks
672 are just beginning to be developed.
673
674 • (L) Wide and Metropolitan Area Network2

2 Several of the shown networks could be based on WAN technologies. However since those networks –

16
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

675 Networks that can use public or private infrastructures. They inter-connect network devices
676 over a wide area (region or country) and are defined through SLAs (Service Level
677 Agreement).
678
679 • (M) Industrial Fieldbus Area Network
680 Networks that interconnect process control equipment mainly in power generation (bulk or
681 distributed) in the scope of smart grids.
• (J) Interchange networks
• (K) Trans-regional networks

• (I) Balancing networks

Market
• (H) Enterprise Networks
• (G) Intra-Control center Networks

Enterprise • (L) Wide and Metropolitan

• Area Networks

• (F) Inter-substation Networks

Operation
• (E) Intra-substation Networks

• (D) Low-end intra-substation

Station Networks

• ( C) Field Area Networks

Field

• (B) Neighborhood Networks

Process

• (A) Subscriber Access Network

Customer
Generation Transmission Distribution DER
premise
• (M) Industrial Fieldbus
Networks
682
683 Figure 2: Mapping of communication networks on SGAM Communication Layer
684 Note 1: These areas of responsibility are an example mapping and cannot be normative to all business
685 models.
686 Note 2: It is assumed that that sub-networks depicted in the above figure are interconnected (where
687 needed) to provide end-to-end connectivity to applications they support. VPNs, Gateways and
688 firewalls could provide means to ensure network security or virtualization.

A. can be run / managed by different stakeholders,

B. could provide different level of security or different SLAs
- they are depicted separately. It should be noted however that this is a logical view and that in practice
multiple logical networks can be implemented using a single WAN technology. Implementation design
choices are beyond the scope of this report

17
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

689

690 3.3 Applicability statement of the Communication Technologies to the Smart Grid
691 Sub-networks
692
693 The following table provides an applicability statement indicating the standardized communication
694 technologies to the Smart Grid sub-networks depicted in the previous sub-clause. As per
695 Recommendation 6, the choice of a technology for a sub-network is left to implementations, which
696 need to take into account a variety of deployment constraints.
697
698 Note: This report addresses communication technologies related to smart grid deployment. It includes
699 communication architecture and protocols that could be used in smart metering deployments as well
700 as other use cases (like feeder automation, FLISR etc.). For AMI only specific standards, refer to
701 CEN/CLC/ETSI TR 50572 and other future deliverables as listed in SMCG_Sec0025_DC_V0.3 Work
702 Program Document.
703

18
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

704 Table 1: Applicability statement of the communication technologies to the smart grid sub-networks

us
re
rk

n
ork ood

ld b
ti o

tio

ent
two

al

nal
tio r a

tre ol

Fi e
ge
s ta

sta
t
h
ac c ri ber

ac

gio

atio
sub nd i n

cen ntr
ne

rise
rea

g
u

han
sub
sub

l
dat

ci n
o

tria
s re
o
ess

sn
b
sc

erp
s ta
ld a

ra c
-e
i gh

erc
an
ra-

er-
tw

us
Sub

ra

n
Low

WA
Tr a

Tr a
Ent

Bal

Ind
Ne
Ne
Fie

I nt

I nt

I nt

I nt
int
A B C D E F G H I J K L M
Narrow band
PLC (Medium
and Low
voltage) x x x
Narrow band
PLC (High and
very High
voltage) x x
Broadband PLC x x
IEEE 802.15.4 x x x
IEEE 802.11 x x x x
IEEE 802.3/1 x x x x x x
IEEE 802.16 x x x
ETSI TS 102 887 x x
IPv4 x x x x x x x x x x x x x x
IPv6 x x x x x x x x x x x x x x
RPL / 6LowPan x x x
IEC 61850 x x x x x x
IEC 60870-5 x x x x
GSM / GPRS /
EDGE x x x
3G / WCDMA /
UMTS / HSPA x x x x x x x x x x
LTE/LTE-A x x x x x x x x x x x x x
SDH/OTN x x x x x x x x x x x x x x
IP MPLS / MPLS
TP x x x x x x x x x x x x x x
EN 13757 x
DSL/PON x x x x
Higher layer
comm protocol x x x x x x x x x x x x
705 3

3 IEEE GEPON and EPON are considered to be part of DSL/PON line

19
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

706 4 Communication Standards for the Smart Grid

707 4.1 Internet Protocol Technology

708 4.1.1 The Key Advantages of Internet Protocol

709 An end-to-end IP Smart-Grid architecture can leverage 30 years of Internet Protocol technology
710 development [RFC 6272] guaranteeing open standards and interoperability as largely
711 demonstrated through the daily use of the Internet and its two billion end-users [Stats].

712 Note: Using the Internet protocol suite does not mean that an infrastructure running IP has to be
713 an open or publicly accessible network–indeed, many existing mission-critical but private
714 and highly secure networks leverage the IP architecture, such as inter- banking networks,
715 military and defense networks, and public-safety and emergency-response networks, to
716 name a few.

717 One of the differences between Information and Communications Technology (ICT) and the more
718 traditional power industry is the lifetime of technologies. Selecting the IP layered stack for Smart
719 Grid infrastructure brings future proofing through smooth evolutionary steps that do not modify the
720 entire industrial workflow. Key benefits of IP are:

721 • Open and Standards-based: Core components of the network, transport and applications
722 layers standardized by the Internet Engineering Task Force (IETF) while key physical, data
723 link, and applications protocols come from usual industrial organizations, such as, IEC,
724 ANSI, SAE, IEEE, ITU, etc.
725 • Lightweight: Devices installed in the last mile such as smart meters, sensors, and
726 actuators are not like PC and servers. They have limited resources in terms of power, CPU,
727 memory, and storage. Therefore, an embedded networking stack must work on few kilobits
728 of RAM and a few dozen kilobits of Flash memory. It has been demonstrated over the past
729 years that production IP stacks perform well in such constrained environments.
730 • Versatile: Last mile infrastructure in Smart Grid has to deal with two key challenges. First,
731 one given technology (wireless or wired) may not fit all field deployment’s criteria. Second,
732 communication technologies evolve at a pace faster than the expected 15 to 20 years
733 lifetime of a smart meter. The layered IP architecture is well equipped to cope with any type
734 of physical and data link layers, making it future proof as various media can be used in a
735 deployment and, over time, without changing the whole solution architecture and data flow.
736 • Ubiquitous: All recent operating systems releases from general-purpose computers and
737 servers to lightweight embedded systems (TinyOS, Contiki, etc.) have an integrated dual
738 (IPv4 and IPv6) IP stack that gets enhanced over time. This makes a new networking
739 feature set easier to adapt over time.
740 • Scalable: As the common protocol of the Internet, IP has been massively deployed and
741 tested for robust scalability. Millions of private or public IP infrastructure nodes, managed
742 under a single entity have been operational for years, offering strong foundations for
743 newcomers not familiar with IP network management.
744 • Manageable and Secure: Communication infrastructure requires appropriate management
745 and security capabilities for proper operations. One of the benefits of 30 years of
746 operational IP networks is its set of well-understood network management and security
747 protocols, mechanisms, and toolsets that are widely available. Adopting IP network
748 management also helps utility operational business application by leveraging network-

20
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

749 management tools to improve their services, for example when identifying power outage
750 coverage through the help of the Network Management System (NMS).
751 • Stable and resilient: With more than 30 years of existence, it is no longer a question that
752 IP is a workable solution considering its large and well-established knowledge base. More
753 important is how we can leverage the years of experience accumulated by critical
754 infrastructures, such as financial and defense networks as well as critical services such as
755 Voice and Video that have already transitioned from closed environments to open IP
756 standards. It also benefits from a large ecosystem of IT professionals that can help
757 designing, deploying and operating the system solution.
758 • End-to-end: The adoption of IP provides end-to-end and bi-directional communication
759 capabilities between any devices in the network. Centralized or distributed architecture for
760 data manipulations are implemented according to business requirements. The removal of
761 intermediate protocol translation gateways facilitates the introduction of new services.

762 4.1.2 IP layered architecture

763 The IP architecture offers an open standard layered architecture that perfectly fit in the smart grid
764 new requirements. It offers also a migration path for some non-IP protocols and implementations
765 like DNP, Modbus and KNX.
766
767 The following diagram is representing such architecture:
768
Web Services/EXI IEC 61968 CIM
Layer

SNMP, IPfix,
App.

IEEE
DNS, NTP, ANSI C12.19/C12.22 IEC 61850 IEC 60870 DNP EN50090 MODBUS
1588
HTTPS/CoAP SSH,… DLMS/COSEM, M&M, OSGP

TCP/UDP
Functionality
Network
Comm. Network Layer

Routing – RPL IPv6 / IPv4 Addressing, Multicast, QoS, Security

Access control and security layer

6LoWPAN (RFC 6282) IETF RFC 2464 ETSI 102 887-2 IETF RFC 5072 IETF RFC 5121
Functionality
PHY / MAC

IEEE 802.15.4 802.15.4e MAC enhancements

MAC IEEE 802.15.4 IEEE
MAC (including FHSS) P1901.2 IEEE 802.3 IEEE 802.16
ETSI 102 887-1 2G / 3G / LTE
IEEE 802.15.4 IEEE 802.15.4g Ethernet WiMax
Cellular
2.4GHz DSSS (FSK, DSSS, OFDM)
769
770 Figure 3: IP standard protocol layers
771 Note: this Protocol Architecture is promoting the use of IP in the protocol layers; innovative data
772 transport solutions may be developed in the future.

773 4.1.3 The Technical Components of IPv6 Smart Grid Infrastructure

774 Today, the Internet runs mostly over IP version 4 (IPv4), with exceptions in academic and research
775 networks, leading Internet Service Providers or Enterprises, and government networks (where IPv6
776 is increasingly being deployed). However, the Internet faces a major transition [OECD] due to the
777 exhaustion of address pool managed by IANA since February 2011. With little existing IPv4
778 networking legacy in the areas of AMI and Distribution Automation, there is an opportunity to start
779 deploying IPv6 as the de facto IP version from Day One. The industry has been working on IPv6
780 for nearly 15 years, and the adoption of IPv6 —which provides the same IP services as IPv4 would
781 be fully aligned with numerous recommendations (U.S. OMB and FAR, European Commission
782 IPv6 recommendations, Regional Internet Registry recommendations, and IPv4 address depletion
783 countdown) and latest 3G cellular evolution known as LTE (Long Term Evolution).

21
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

784 Moreover, all new developments in relation to IP for Smart Objects and LLNs as discussed above,
785 make use of or are built on IPv6 technology. Therefore, the use of IPv6 for Smart Grid deployment
786 benefits from several features, some being extensively reviewed in the next sections:

787 • A huge address space accommodating any expected multi-millions meter’s deployment
788 (AMI), thousands of sensors (DA) over the hundred thousands of secondary substations
789 and additionally all standalone meters. It includes additional flexibility of address
790 configuration that helps adapting with the size of deployments as well as the need to lower
791 field workers tasks when installing small devices. The structure of the IPv6 address is also
792 flexible enough to manage a large number of sub-networks that may be created by futures
793 services such as e-vehicle charging stations or distributed renewable energy
794 • IPv6 is used IP version for meter communication over RF Mesh wireless (IEEE 802.15.4g,
795 DECT Ultra Low Energy) and Power Line Communications infrastructures (IEEE P1901.2)
796 using the 6LoWPAN adaptation layer that only defines IPv6 as its protocol version.
797 • IPv6 is the de facto IP version for the standardized IETF Routing Protocol for Low Power
798 and Lossy Networks (RPL)—IETF RoLL WG—RPL is an IPv6-only protocol.

799 4.1.4 IPv6 Addressing

800 The adoption of IPv6 requires an Energy Provider to consider all steps required by an IP network
801 design and particularly an understanding of IPv6 addressing and how internal policies may help
802 the operations.

803 Global, public, and private address space have been defined for IPv6, therefore a decision must be
804 made regarding which type of IPv6 addressing scheme should be used in utility networks. Global
805 addressing means the utility must follow the Regional Internet Registries (RIR) policies (such as
806 ARIN https://www.arin.net/policy/nrpm.html) to register an IPv6 prefix that is large enough for the
807 expected deployment and its expansion over the coming years. This does not mean the address
808 space allocated to the infrastructure must be advertised over the Internet allowing any Internet
809 users to reach a given device. The public prefix can be advertised if representing the entire utility
810 corporation–or not–and proper filtering mechanisms are in place to block all access to the Field
811 Area Networks and devices. On the other end, using a private address space means the prefix not
812 be advertised over the Internet, but, in case there is a need for B2B services and connectivity, a
813 private address would lead to the deployment of additional networking devices known as IPv6-IPv6
814 NPT (Network Prefix Translation, RFC 6296) gateways.

815 Once the IPv6 addressing structure (see RFC 4291, 4193) and policies are well understood and a
816 prefix is allocated to the infrastructure, it is necessary to structure the addresses according to the
817 number of sites and end- points that would connect to it. This is no different to what an ISP or a
818 large Enterprise has to perform. (See 6NET)

819 Internal policies may be defined by the way an IPv6 address is assigned to an end-device, by
820 using a global or private prefix.

821 Three methods to set an IPv6 address on an end-point are available:

822 • Manual configuration–This is appropriate for Head-End and NMS servers that never
823 change their address, but is inappropriate to millions of end-points, such as meters, in
824 regards to the associated operational cost and complexity
825 • Stateless auto-configuration–A mechanism similar to Appletalk, IPX and OSI, meaning
826 an IPv6 prefix gets configured on a router interface (interface of any routing device such as
827 a meter in a mesh or PLC AMI network), which is then advertised to nodes attached to the

22
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

828 interface. When receiving the prefix at boot time, the node can automatically set-up its IPv6
829 address
830 • Stateful auto-configuration–Through the use of DHCPv6 Individual Address Assignment,
831 this method requires DHCPv6 Server and Relay to be configured in the network but
832 benefits of a strong security as the DHCPv6 process can be coupled with AAA
833 authentication, population of Naming Services (DNS) available for Head-End and NMS
834 applications. The list above is the minimum set of tasks to be performed, but as already
835 indicated; you must also establish internal policies and operational design rules. This is
836 particularly true when considering security and management tasks such as registering IPv6
837 addresses and names in DNS (Domain Name System) and in NMS (network management
838 station(s) or setting-up filtering and firewalling across the infrastructure.

839 4.2 Field, Neighborhood, home / building area networks overview

840 4.2.1 Introduction

841 These networks are different from the access network and Wide area network in the sense that
842 they mainly interconnect the end devices each together as an autonomous network or to the
843 access network. Some examples of these networks are:
844 • HAN (Home area networks which interconnects home devices)
845 • PAN (Personal area networks which interconnects body sensors, personal display,
846 personal phones or smart phones etc…
847 • FAN (Field Area networks which in the case of smart grid interconnects smart meters,
848 power sensors, EVs, etc…).
849 • NAN (Neighbor area networks: other name for the FAN)
850
851 This section will list the main specifications of technologies that are based on open standards.

852 4.2.2 Power Line Technology

853 4.2.2.1 Introduction

854 Under the term of Power Line Communication (PLC) a wide class of technologies is identified
855 which allow the exploitation of almost all type of power line cables. PLC can be applied to multiple
856 Smart Grid sub-networks such as inter substation networks and neighbor area networks.
857
858 The figure below, provided for the sole purpose of illustration, gives some examples of PLC
859 communications.

23
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

860
861 Figure 4: Example of PLC usage
862 PLC has been used since long time providing for both specific solutions for power utility
863 applications as well as communications access solutions and more recently due to increasingly
864 interest and market needs has been extended to cover in-home systems needs.
865
866 Furthermore power lines provide a communication path that puts the utility in control of the
867 communication capabilities.

868 4.2.2.2 PLC Technologies Classification

869 For our initial considerations, PLC technology can be classified taking into account three key
870 features:
871 • The level of voltage where they are operated (Low, Medium, High, Extra High Voltage
872 LV/MV/HV/EHV)
873 • The allocated ranges of frequencies
874 • Data rates (throughput)
875
876 A) Narrowband PLC technologies, also known as Distribution Line Carrier (DLC), is
877 capable of data rates of few kilobits per second operate in Europe in the so called
878 CENELEC bands:
879 • CENELEC A band: 3–95 kHz reserved exclusively to power utilities;
880 • CENELEC B band: 95–125 kHz any application;
881 • CENELEC C band: 125–140 kHz in-home networking;
882 • CENELEC D band: 140–148.5 kHz alarm and security systems.
883
884 In countries out of Europe Narrowband PLC could be allocated within 3–500 kHz bands.
885

24
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

886 Recently advanced multicarrier modulation technologies, using the same allocated CENELEC
887 bands, made it possible to reach data rates in the order of hundreds of kilobits per second.
888
889 B) Broadband PLC (BPL) technologies supporting both high data rate bidirectional
890 transmission as well as last mile internet-access providing for data rates ranging
891 between tens of kilobits per second up to ten of megabits per second. They can be
892 operated over Medium and Low Voltage electricity Power Lines.

893 4.2.2.3 PLC Standards

894 There are several existing and ongoing standards that deal with PLC communications. These
895 standards have been ratified by Standards Developing Organizations (SDOs) like IEC, ISO,
896 CENELEC, ETSI, ITU-T, and IEEE or based on industry fora or alliances.
897
898 Table 2: Relevant Narrowband PLC Standards
899 Note: fora/consortia specifications are depicted in Appendix A.
SDOs - Alliance -
Standard Name Frequency Bands Power Line Segment
Industry

High and Extra High

IEC IEC62488-X 40-492kHz (1MHz)
Voltage

Medium and Low

IEC IEC 61334-X 3-500kHz
Voltage

IEC61334-3-1
IEC61334-5-1 CENELEC A
IEC Low Voltage
IEC61334-5-2 20kHz-95kHz
IEC61334-4-32
ISO/IEC 14908-3 125 kHz to 140 kHz Low Voltage
A (86kHz & 75.543kHz
ISO/IEC ISO/IEC 14908-3 125kHz-140kHz
Low Voltage
F_c=131.579kHz)
CENELEC A/B/C
PL110 (95kHz-125kHz F-
ISO/IEC 14543-3-5
ISO/IEC c=110kHz)
EN 50090 Low Voltage
BS PL132 (125kHz-140kHz F-
c=132.5kHz)

CENELEC A (G.hnem)
CENELEC B (G.hnem)
G.9955 (PHY) Medium and Low
ITU-T CENELEC CD (G.hnem)
G.9956 (DLL) Voltage

ETSI TS 103 908 9 kHz to 95 kHz Low Voltage

CENELEC A Medium and Low

IEEE P1901.2 P1901.2 (Draft)
Voltage

25
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

900
901
902
903 Table 3: Relevant Broadband PLC Standards
904 Note: fora/consortia specifications are depicted in Appendix A
SDOs - Alliance -
Standard Name Frequency Bands Power Line Segment
Industry

CLC prEN 50412-4 - LRWBS 2-4MHz Low Voltage

ISO/IEC ISO/IEC 12139-1 2-30MHZ Low Voltage

ITU G.h :
- G.9960 (PHY)
ITU - G.9961 (DLL) 2-100MHz Low Voltage
- G.9962 (MIMO)
- G.9964 (PSD)

IEEE IEEE 1901 2-50MHz Low Voltage

905

906 4.2.3 Mesh Network technologies

907 4.2.3.1 RF mesh network

908 4.2.3.1.1 Introduction

909 A RF mesh network (or wireless mesh network) is a communications network made up of radio
910 nodes organized in a peer-to-peer or mesh topology. In this topology, mains-powered radio nodes
911 route and forward data traffic on behalf of other adjacent, mains-powered radio nodes; routing and
912 forwarding of traffic can occur at L2 or L3. In the Smart Grid, a RF mesh network is most often
913 used for “last mile” communications, often referred to as a Field Area Network (FAN) or
914 Neighborhood Area Network (NAN). RF meshes support 2-way communication involving the
915 following Domains: Markets, Operations, Distribution and Customer (as described in the
916 Conceptual Model). The RF mesh network typically consists of mains-powered RF nodes,
917 including but not limited to:
918 • Access Points: a dedicated infrastructure device that provides ingress and egress to the
919 FAN via a WAN. The WAN interface is typically an IP-based backhaul that uses cellular
920 connectivity (e.g., 3G), xDSL, or other commodity backhaul connectivity collocated at DSO
921 substations. These devices may also be referred to as concentrators, take-out points, or
922 ingress/egress devices. These devices might perform simply as a router or have more
923 complex application state and persistent storage.
924 • Relays: a dedicated infrastructure device that is designed to extend coverage and range to
925 the FAN. These devices are often referred to as repeaters.
926 • RF nodes such as RTUs connected to devices such as EVSEs, transformer/substation
927 monitors, faulted circuit indicators, switch reclosers, load tap changers, capacitor bank
928 controllers, streetlights, etc.

26
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

929 • RF nodes deployed in Smart Meters (either tightly integrated or as “standalone”

930 telecommunications hubs or multi-utility controllers) may also be leveraged to route and
931 forward certain distribution automation traffic within the mesh in accordance to DSO policy.
932
933 Some typical Smart Grid applications that may be supported by a RF mesh network are:
934 • Conservation voltage reduction
935 • Voltage monitoring
936 • Transformer monitoring
937 • FLISR
938 • Grid reliability applications such as with teamed switch reclosers
939 • EVSE monitoring and round-robin charging schemes
940 • DER management including integrated micro-inverters
941 • Load control applications such as DR or DSM
942
943 Smart Grid applications may utilize a mesh network exclusively within an orthogonal, overlay
944 network, but in many cases, the same RF mesh FAN may be configured to interface with the
945 Smart Metering infrastructure. In the latter case, the communications architecture should not
946 preclude the exchange of smart metering and smart grid traffic, but appropriate policy mechanisms
947 (e.g., authentication, authorization, network admission control) need to intrinsic to the
948 implementation. An often-cited advantage of RF mesh networks is that it allows for the distribution
949 of compute power and intelligence deep into the network, which in turn allows for local, low
950 latency, cost-effective communications.
951
952 One advantage of mesh networks is reliability and redundancy by way of rich path diversity; mesh
953 nodes may typically count many adjacencies or “neighbors”. A radio integrated into a Smart Grid
954 device may also associate with one or more concentrators (for ingress/egress diversity) and with
955 other RF mesh nodes, which act as stepping-stones for extending the coverage. All together this
956 forms a mesh network with multiple alternative communication paths for a node to reach multiple
957 concentrators. When one node can no longer operate, the rest of the nodes can still communicate
958 with one another, directly or through one or more intermediate nodes. The concentrators may
959 contain intelligence ensuring that communication is always updated and optimized.

960 4.2.3.1.2 Radio frequency

961 A wide range of radio frequency bands may be exploited by RF mesh technologies that could be
962 operated under “licensed”, “light-licensed” or “unlicensed” regulatory regimes.
963 For Field Area Network RF meshes, spectrum bands below 1 GHz are often preferred. Standards
964 have been defined that exploit spectrum in the bands 169 MHz, 433 MHz, 444 MHz, 868 MHz
965 used for short range devices (SRD), and 870 – 876 MHz. Some RF mesh implementations are
966 also available in the band 2.45 GHz. The standards that cover these particular bands are EN
967 13757-4, EN 13757-5, IEEE 802.15.4g, IEEE 802.15.4-2006, and ETSI TS 102 887-1.

968 4.2.3.2 Mesh networking technologies using power line

969 When you are using power line as the carrier media for information transport, you are using a
970 shared media (the copper) sensitive to radio interferences and signal attenuation.
971 The issues that you are getting are quite similar to the ones you will get using Air Radio
972 Frequency.
973

27
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

974 The use of repeaters along the line has been very challenging to deploy, as there is no way to
975 formally predict where to position these repeaters. Signal level is fluctuating and the antenna that
976 the power line is forming is very sensitive to external radio interferences.
977
978 One solution to this issue is to use routing mesh technologies equivalent to RF mesh. Each of the
979 equipment along the line is acting as a router in the same way we do for RF mesh.
980
981 The routing protocol and routing algorithms are able to compute the best path between these
982 equipments while the conditions are changing.
983
984 RPL routing protocol (IETF RFC 6550) is designed to satisfy these requirements.

985 4.2.4 Physical and MAC layers

986 The following Technologies are a set of those most well known & collected in the meetings there is
987 no aim to be exhaustive.

988 4.2.4.1 P1901.2 - Standard for Low Frequency (less than 500 kHz) Narrow Band Power Line
989 Communications for Smart Grid Applications
990
991 http://grouper.ieee.org/groups/1901/2/
992
993 This standard specifies communications for low frequency (less than 500 kHz) narrowband power
994 line devices via alternating current and direct current electric power lines. This standard supports
995 indoor and outdoor communications over low voltage line (line between transformer and meter,
996 less than 1000 V), through transformer low-voltage to medium-voltage (1000 V up to 72 kV) and
997 through transformer medium-voltage to low-voltage power lines in both urban and in long distance
998 (multi- kilometre) rural communications. The standard uses transmission frequencies less than 500
999 kHz. Data rates will be scalable to 500 kbps depending on the application requirements. This
1000 standard addresses grid to utility meter, electric vehicle to charging station, and within home area
1001 networking communications scenarios. Lighting and solar panel power line communications are
1002 also potential uses of this communications standard. This standard focuses on the balanced and
1003 efficient use of the power line communications channel by all classes of low frequency narrow
1004 band (LF NB) devices, defining detailed mechanisms for coexistence between different LF
1005 NB standards developing organizations (SDO) technologies, assuring that desired bandwidth may
1006 be delivered. This standard assures coexistence with broadband power line (BPL) devices by
1007 minimizing out-of-band emissions in frequencies greater than 500 kHz. The standard addresses
1008 the necessary security requirements that assure communication privacy and allow use for security
1009 sensitive services. This standard defines the physical layer and the medium access sub-layer of
1010 the data link layer, as defined by the International Organization for Standardization (ISO) Open
1011 Systems Interconnection (OSI) Basic Reference Model.

1012 4.2.4.2 IEEE 802.3 Ethernet

1013 Ethernet is a widely used networking technology spanning the physical layer and the Media
1014 Access Control (MAC) layer. Ethernet is standardized in IEEE 802.3-2008 and ISO/IEC 8802-
1015 3:2000. Ethernet is specified for the exchange of data between devices (e.g., PC, printer, switch)
1016 connected in a wired network. Ethernet was originally specified for Local Area Networks (LAN), of
1017 which the Home Area Network (HAN) is an application specific subset. Ethernet is also applied to,
1018 e.g., Metro networks or Wide Area Networks. Ethernet is deployed within sub-stations and power
1019 generation plants.
1020
1021 Ethernet is based on Carrier Sense Multiple Access with Collision Detection (CSMA/CD) as a
1022 shared media access method. Today, point-to-point full duplex communication is also used. The

28
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1023 standard defines the frame format for the data communication, the data rates, the line codes, the
1024 cable types, and interfaces.
1025
1026 The specified data rates are 10 Mbit/s, 100 Mbit/s (Fast Ethernet), 1000 Mbit/s (Gigabit Ethernet)
1027 and 10 GBit/s. 40-Gbit/s and 100-Gbit/s.
1028
1029 Table 4 contains a sample of specified interface types with the corresponding technical data.
1030 Several media types as coax cable, twisted-pair cable and fiber cable are possible. The interface
1031 types have different line codes.
1032
1033 Table 4: Sample of specified interface types
Interface type Data rate Cable type Maximum Line code
segment length
10Base2 10 Mbit/s Thin coax 185 m Manchester
(half duplex) code
10BaseT 10 Mbit/s 2-pairs CAT3 or 100 m Manchester
(half duplex) CAT5 cable code
20 Mbit/s
(full duplex)
100BaseTX 100 Mbit/s 2-pairs CAT5 100 m 4B/5B
(half duplex) unshielded
200 Mbit/s cable
(full duplex)
1000BaseT 1000 Mbit/s 4-pairs CAT5 100 m PAM5
(half duplex) cable
2000 Mbit/s
(full duplex)
1000BaseSX 1000 Mbit/s 2 multi-mode 550 m 8B/10B
(half duplex) fiber cables
2000 Mbit/s
(full duplex)
1034
1035 Ethernet is compatible with some other protocols. IEEE 802.11 supports the Ethernet data format.
1036 The Media Redundancy Protocol is a solution to compensate for failures in a ring topology like the
1037 Rapid Spanning Tree Protocol in IEEE 802.1 (LAN bridging and architecture). The Media
1038 Redundancy Protocol is specified in IEC 62439 and can be applied to Ethernet networks. IEC
1039 62439 is used in industrial automation. Recently this standard has been referenced by IEC TC57 in
1040 IEC TR 61850-90-4 to be applied to substations.
1041
1042 Ethernet is extended to be applicable in telecommunications networks with the operator’s
1043 requirements. These extensions are called Carrier Ethernet. Metro Ethernet Forum (MEF) defined
1044 Carrier Ethernet Services to be certified, which the operator can provide their customers:
1045  E-line (point-to-point Ethernet service over a WAN),
1046  E-LAN (multipoint-to-multipoint Ethernet service),
1047  E-tree (point-to-multipoint Ethernet service).
1048 The Carrier Ethernet services are carried over the WAN using different technologies:
1049  Ethernet over SDH or OTN (ITU-T),
1050  Ethernet over MPLS / MPLS-TP (IETF),
1051  Provider Backbone Bridge – Traffic Engineering PBB-TE (IEEE),
1052
1053 PBB-TE supports connection oriented packet transport, traffic engineering and OAM.

29
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1054 Synchronous Ethernet (G.8262), Precision Time Protocol (IEEE 1588), and Audio Video Bridges
1055 (AVB, IEEE 802.1) can be used for time sensitive applications.

1056 4.2.4.3 IEEE 802.11 (WIFI) [5]

1057 Technology Overview

1058 There is a set of standards comprised under the IEEE 802.11 family [7], aiming at low cost
1059 wireless LAN functionality, with the goal of providing a service equivalent to Ethernet layer 2 wired
1060 connectivity. These standards use Direct Sequence Spread Spectrum (DSSS) and Multi Carrier
1061 Orthogonal Frequency Division Multiplexing (OFDM) radio technologies. Unlike other wireless
1062 communication technologies, IEEE 802.11 makes use of unlicensed frequency bands in the range
1063 of 2.4 and 5GHz. This fact has the following key attributes:

1064 • Plenty of equipment and vendors available.

1065 • Guaranteed interoperability via an independent product certification entity (WiFi Alliance).
1066 • Worldwide availability of (at least some channels) on the same frequency bands.
1067 • Transmission data rates of the order of tens of megabits can be achieved (802.11a/g
1068 technology has a limit of 54Mbps).
1069 • Low cost of the devices and no exploitation costs for the service. On the other hand, there
1070 are some drawbacks that must be taken into account:
1071 • The maximum allowed radiated power (EIRP) is very low, typically 100mW in many
1072 countries, including Europe. The link distance is therefore limited by both transmitted power
1073 and antenna directivity.
1074 • These frequency bands are very sensible to attenuation from water molecule absorption. In
1075 this way fog, rain and snow can degrade seriously the link power budget.
1076 • The frequency bands are free for anyone to use them, and thus there may be some
1077 interference problems arising from congestion, both by 802.11 devices and other
1078 appliances using the same unlicensed band. This is particularly important in the 2.4GHz
1079 ISM band.
1080 • Last, but not least, security aspects are mandatory, as IEEE 802.11 systems can be easily
1081 sniffed. Strong encryption mechanisms, such as WPA and preferably WPA2, have proved
1082 secure enough to let this technology be used in different environments such as meter
1083 reading.
1084 • These standards were not designed with lowest power consumption in mind, so these
1085 technologies have slightly higher standby power consumptions than other WLAN/WPAN
1086 solutions, usually in the order of 1W. The IEEE 802.11 family currently includes multiple
1087 over-the-air modulation techniques that all use the same basic protocol. The segment of the
1088 radio frequency spectrum varies between countries and includes 2.4 GHz and 5GHz.
1089
1090 IEEE 802.11b and 802.11a were the first widely accepted wireless networking standard, followed
1091 by 802.11g and then 802.11n. Other standards in the family (c–f, h, and j) are service amendments
1092 and extensions or corrections to previous specifications.
1093
1094 IEEE 802.11n is based on a new multi-streaming modulation technique and at the time of
1095 preparation of the present document, is still under draft development, although proprietary
1096 products based on pre-draft versions of the standard are available on the market.
1097

30
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1098 Frequency Bands IEEE 802.11 technology operates in unlicensed frequency bands. Some of
1099 these bands are not available worldwide, even though frequency spectrum harmonization tasks
1100 have been carried out since these technologies hit the market. The frequency bands in use are:
1101
1102 • 2.4GHz ISM band for IEEE 802.11b, g, n.
1103 • 5GHz band (5.15-5.825GHz) for IEEE 802.11a, n.
1104
1105 Key Applications The relative low cost and use of unlicensed frequency bands makes possible
1106 the usage of IEE802.11 technologies in many application scenarios, such as the following: •
1107 Provide wireless bridging between fixed Ethernet networks. In this case a fixed Ethernet network
1108 can be reached by means of two wireless bridges, which create a wireless link between them, and
1109 create a layer 2 bridge. This is very useful when the deployment of a fixed Ethernet connection is
1110 not feasible due to physical constraints or high costs. Link distances in the order of kilometres may
1111 be reached using standard equipment.

1112 4.2.4.4 IEEE 802.16 (WIMAX)[5]

1113 Technology Overview

1114 IEEE802.16 is working group within IEEE focused in Wireless Metropolitan Area (WMAN) access
1115 technology [8]. Since its initial conception, two main standards have been developed:

1116 • 802.16d - fixed IEEE 802.16d (“802.16-2004”) is aimed at fixed applications and providing
1117 a wireless equivalent of DSL broadband data.
1118
1119 802.16d is able to provide data rates of up to 75 Mbps and as a result it is ideal for fixed,
1120 DSL replacement applications. It may also be used for backhaul where the final data may
1121 be distributed further to individual users. Cell radii are typically up to 75 km.
1122 • 802.16e - Nomadic / Mobile
1123 This standard is also known as “802.16-2005”. It currently provides the ability for users to
1124 connect to a cell from a variety of locations, and there are future enhancements to provide
1125 cell handover.
1126
1127 802.16e is able to provide data rates up to 15 Mbps with cell radius distances typically 2÷4
1128 km.
1129
1130 Frequency Bands

1131 The IEEE 802.16 standard allows data transmission using multiple broadband frequency ranges.

1132 The original 802.16a standard specified transmissions in the range 10÷66 GHz, but 802.16d
1133 allowed lower frequencies in the range 2 to 11 GHz. The lower frequencies used in the later
1134 specifications provide improved range and better coverage within buildings; this means that
1135 external antennas are not required.

1136 Different bands are available for IEEE802.16 applications in different parts of the world.

1137 The frequencies commonly used are 3.5 and 5.8 GHz for 802.16d and 2.3, 2.5 and 3.5 GHz for
1138 802.16e but the use depends upon the countries.

31
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1139 The 5.8GHz band is not available in most European countries.

1140 IEEE802.16 uses OFDM (Orthogonal Frequency Division Multiplex) as its modulation scheme. For
1141 802.16d, 256 carriers are used, but for 802.16e the system is scalable according to the conditions
1142 and requirements.

1143 More advanced versions including 802.16e utilize MIMO (Multiple Input Multiple Output) and
1144 support for multiple antennas. The use of these techniques provides potential benefits in terms of
1145 coverage, self-installation, power consumption, frequency re-use and bandwidth efficiency.

1146 The IEEE 802.16a (256 OFDM PHY) and ETSI HIPERMAN (High Performance Radio Metropolitan
1147 Area Network) standards share the same PHY and MAC. The purpose of 802.16e is to add limited
1148 mobility to the current standard which is designed for fixed operation.

1149 Key Applications

1150 IEEE802.16 technologies are further along in terms of deployments with several operators
1151 throughout the world using it to provide fixed wireless broadband services. But so far, the
1152 technology has had a slow start as a mobile technology.

1153 Most of new 802.16-based operators come from the fixed network space, and they are looking to
1154 use these technologies as an enhanced DSL service.

1155
1156 Figure 5: WiMAX usage model

1157 4.2.4.5 IEEE 802.15.4

1158 http://www.ieee802.org/15/pub/TG4.html
1159
1160 The IEEE 802.15.4 standard ([IEEE-802-15-4]) describes a LR WPAN (Low Rate Wireless
1161 Personal Area Network). In addition to low rate the standard also attempts to achieve several goals
1162 simultaneously: extremely low cost, short-range operation with a reasonable battery life. Finally,
1163 the networks should be simple to install and offer reliable data transfer.
1164
1165 The two major parts of the standard are the PHY and the MAC. These two layers are the common
1166 foundation layers of the OSI model and are found in almost all other communication protocols.
1167

32
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1168 The PHY layer describes the modulation, operating frequency, over the air data rates, channels
1169 and other important aspects of radio operation such as receiver sensitivity and transmission power.
1170
1171 Frequency range
1172 There are four frequency ranges that the standard defines (IEEE 802.15.4 C defines the Chinese
1173 band). The ranges are:
1174 China: 779 to 787 MHz
1175 Europe: 863 to 870 MHz
1176 North America: 902 to 928 MHz
1177 Worldwide: 2400 to 2483.5 MHz
1178
1179 Channels
1180 The Chinese band allows for 4 channels with channel spacing of 2 MHz and center frequencies at
1181 780, 782, 784 and 786 MHz. One channel is available for the European band at 868.3 MHz. Ten
1182 channels are available in the North American ISM band with 2 MHz channel spacing and center
1183 frequencies at 906, 908, 910, 912, 914, 916, 918, 920, 922 and 924 MHz. Finally, 16 channels are
1184 available in the worldwide band with 5 MHz channel spacing and center frequencies at 2405, 2410,
1185 2415, 2420, 2425, 2430, 2435, 2440, 2445, 2450, 2455, 2460, 2465, 2470, 2475 and 2480 MHz.
1186
1187 Modulation
1188 In IEEE 802.15.4 standard for the RF transmission there are two modulation modes described,
1189 BPSK (Binary Phase Shift Keying) and O-QPSK (Offset Quadrature Phase Shift Keying.
1190
1191 Bit rates
1192 There are various bit rates within the channels and modulation modes. These are summarized as
1193 follows:
1194 Table 5: 802.15.4 main characteristics
PHY Frequency Band Channel(s) Modulation Bit Rate (kb/s)
868 MHz 0 BPSK 20
902 - 928 MHz 1 - 10 BPSK 40
868 MHz (optional mode) 0 ASK 250
902 - 928 MHz (optional
1 - 10 ASK 250
mode)
868 MHz (optional mode) 0 O-QPSK 100
902 - 928 MHz (optional
1 - 10 O-QPSK 250
mode)
2400 - 2480 MHz 11 - 26 O-QPSK 250
1195
1196
1197 Transmission power
1198 Maximum transmission power is regulated by government agencies such as the FCC in the United
1199 States and ETSI in Europe. Generally, in 802.15.4 systems, a node must be capable of
1200 transmitting at least -3 dBm.
1201 Clear channel assessment
1202
1203 The PHY needs to be able to detect whether or not another radio is transmitting and employ a
1204 method to avoid interference. The mechanism used is CSMA-CA (Carrier Sense Multiple Access
1205 with Collision Avoidance). In this algorithm the radio first listens for energy or modulated data on
1206 the air. If any is sensed the algorithm provides for random wait times (backoffs) to retry the
1207 transmissions.
1208

33
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1209 The Media Access Control (MAC) layer provides the network and higher layers an interface to the
1210 radio (PHY) layer. Its primary function is to limit when each node transmits on the shared media
1211 (the wireless channel) so that transmissions occur one at a time. Like most links, IEEE 802.15.4
1212 supports a Carrier Sense Multiple Access with Collision Avoidance (CSMA-CA) mechanism.

1213 4.2.4.6 ETSI 102 887

1214 The requirement to wirelessly interconnect Smart Meters is one of the responses to the EC
1215 mandate 441 [include reference to CEN, CENELEC and ETSI arch development] for an open
1216 architecture for utility meters. The EC Short Range Device (SRD) Decision and associated
1217 spectrum rules (CEPT REC 70-03) have been identified as suitable regulations to govern
1218 interconnection of meters to the Local Network (LNAP) and Neighborhood Network Access Points
1219 (NNAP), and potential MESH networks built from these APs, identified in the M/441 Technical
1220 Report on Communications.
1221
1222 To that end, reference document ETSI TS 102 887-1 provides the necessary modifications for use
1223 in Europe of the IEEE 15.4 Amendment g, Physical Layer Specification for Low Data Rate
1224 Wireless Smart Meter Utility Networks standard, and specifies the necessary RF performance
1225 parameters to meet the provisional requirements identified in TR 102 886. The PHY specification
1226 in TS 102 887-1 is supported by a MAC specification in TS 102 887-2."

1227 4.2.5 IPv6 adaptation layer

1228 4.2.5.1 6LowPan

1229 http://tools.ietf.org/html/rfc4919
1230
1231 The 6LoWPAN format defines how IPv6 communication is carried in 802.15.4 frames and specifies
1232 the adaptation layer’s key elements. 6LoWPAN has three primary elements:
1233 • Header compression. IPv6 header fields are compressed by assuming usage of common
1234 values. Header fields are elided from a packet when the adaptation layer can derive them
1235 from link-level information carried in the 802.15.4 frame or based on simple assumptions of
1236 shared context.
1237 • Fragmentation. IPv6 packets are fragmented into multiple link-level frames to
1238 accommodate the IPv6 minimum MTU requirement.
1239 • Layer-two forwarding. To support layer-two forwarding of IPv6 datagrams, the adaptation
1240 layer can carry link-level addresses for the ends of an IP hop.
1241
1242 Alternatively, the IP stack might accomplish intra-PAN routing via layer-three forwarding, in which
1243 each 802.15.4 radio hop is an IP hop.
1244

34
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

6LoWPAN is an Adaptation Layer

Diverse Object and Data Models (HTML, XML, …, BacNet, …)

7: app
Application (Telnet, FTP, SMTP, SNMP, HTTP)
4: xport Transport (UDP/IP, TCP/IP)
3: net Network (IPv6)
6LoWPAN
2: link Link
Serial X3T9.5 802.3 802.5 802.11 802.15.4
Modem FDDI 802.3a Token Ring
Ethernet 802.11a
WiFi LoWPAN
802.3i 802.11b
WiFi
ISDN Sonet Ethernet 802.11g
802.3y
Ethernet WiFi802.11n
DSL 10b2802.3ab WiFi
GPRS Ethernet
10bT802.3an WiFi
Ethernet
100bT
1: phy Ethernet
1000bT
1G bT

Source: IPSO Alliance webinar

Jonathan Hui Cisco, David Culler UC berkeley
Zach Shelby Sensinode

1245 BRKGEN-2241 © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Public
49 49

1246 Figure 6: 6LoWPAN within IP protocol stack

1247 4.2.6 IP protocols layer 3 and above

1248 There is a broad consensus that Internet Protocol (IP), especially its most advanced iteration
1249 (IPv6), will serve as an important element in Smart Grid Information networks. This, as there are
1250 several significant attributes that address many smart grid communication requirements, including:
1251 wide range of available standards, proven at scale, large development community, an inherent
1252 benefit of adaptation between applications and the underlying communication medium (affording
1253 application independence of the underlying communication data-link infrastructure), and bindings
1254 with emergent utility app layer protocols such as DLMS/COSEM.
1255
1256 It is expected that the Smart Grid will be formed from a number of interoperable systems. Of
1257 particular note here is the inherent benefit of access to a wide range of available standards. To that
1258 end, the use of IP facilitates the use of a number of existing and future innovations pertaining
1259 privacy/confidentiality and a variety of gateway routing protocols. Specific examples of such
1260 standards are referenced here.

1261 4.2.6.1 IPv6 routing protocol RPL (RFC 6550)

1262 http://tools.ietf.org/html/draft-ietf-roll-rpl
1263
1264 The ROLL Working Group conducted a detailed analysis of the routing requirements focusing on
1265 several applications: urban networks including smart grid, industrial automation, home and building
1266 automation. This set of applications has been recognized to be sufficiently wide to cover most of
1267 the applications of the Internet of Things. The objective of the WG was to design a routing protocol
1268 for LLNs, supporting a variety of link layers, sharing the common characteristics of being low
1269 bandwidth, lossy and low power. Thus the routing protocol should make no specific assessment on
1270 the link layer, which could either be wireless such as IEEE 802.15.4, IEEE 802.15.4g, (low power)
1271 Wi-Fi or Powerline Communication (PLC) using IEEE 802.15.4 such as IEEE P1901.2.

35
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1272
1273 Note that RPL operates at the IP layer according to the IP architecture, and thus allows for routing
1274 across multiple types of link layers, in contrast with other form of “routing” operating at lower layer
1275 (e.g. link layers).
1276
1277 RPL is a Distance Vector IPv6 routing protocol for LLNs that specifies how to build a Destination
1278 Oriented Directed Acyclic Graph (DODAG sometimes referred to as a graph in the rest of this
1279 document) using an objective function and a set of metrics/constraints. The objective function
1280 operates on a combination of metrics and constraints to compute the ‘best’ path. There could be
1281 several objective functions in operation on the same node and mesh network because
1282 deployments vary greatly with different objectives and a single mesh network may need to carry
1283 traffic with very different requirements of path quality. For example, several DODAGs may be used
1284 with the objective to (1) ‘Find paths with best ETX [Expected Transmissions] values (metric) and
1285 avoid non-encrypted links (constraint)’ or (2) ‘Find the best path in terms of latency (metric) while
1286 avoiding battery-operated nodes (constraint)’. The objective function does not necessarily specify
1287 the metric/constraints but does dictate some rules to form the DODAG (for example, the number of
1288 parents, back-up parents, use of load-balancing,...).
1289
1290 The graph built by RPL is a logical routing topology built over a physical network to meet a specific
1291 criteria and the network administrator may decide to have multiple routing topologies (graphs)
1292 active at the same time used to carry traffic with different set of requirements. A node in the
1293 network can participate and join one or more graphs (in this case we call them “RPL instances”)
1294 and mark the traffic according to the graph characteristic to support QoS aware and constraint
1295 based routing. The marked traffic flows up and down along the edges of the specific graph.
1296
1297 RPL and Security
1298 Security is critical in smart object networks but implementation complexity and size is a core
1299 concern for LLNs such that it may be economically or physically impossible to include
1300 sophisticated security provisions in a RPL implementation. Furthermore, many deployments can
1301 utilize link-layer or other security mechanisms to meet their security requirements without requiring
1302 the use of security in RPL. Therefore, the security features in RPL are available as optional
1303 extensions.
1304
1305 When made available, RPL nodes can operate in three security modes. In the first mode, called
1306 "unsecured," RPL control messages are sent without any additional security mechanisms.
1307 Unsecured mode implies that the RPL network could be using other security primitives (e.g. link-
1308 layer security) to meet application security requirements. In the second mode, called "pre-
1309 installed," nodes joining a RPL instance have pre-installed keys that enable them to process and
1310 generate secured RPL messages. In the third mode, called "authenticated", nodes can join as leaf
1311 nodes using pre-installed keys as in pre-installed mode, or join as a forwarding node by obtaining a
1312 key from an authentication authority.
1313
1314 Each RPL message has a secure variant. The level of security (32-bit and 64-bit MAC and ENC-
1315 MAC modes are supported) and the algorithms (CCM and AES-128 are supported) in use are
1316 indicated in the protocol messages. The secure variants provide integrity and replay protection and
1317 confidentiality and delay protection as an added option.

1318 4.2.7 EN 50090 family (KNX)

1319 The CLC EN 50090 describes Home and Building Electronic Systems (HBES).
1320 KNX, the system behind CLC EN 50090, it is the mature HBES system with more than 20 years
1321 experience in the market.
1322
1323 KNX is a worldwide open standard, the associated standards are:

36
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1324  International Standard ISO/IEC 14543-3

1325  European Standards CLC EN 50090 and CEN EN 13321-1
1326  Chinese Standard GB/Z 20965
1327  US Standard ANSI ASHRAE 135).
1328
1329 Home and Building Electronic Systems (HBES) according EN 50090 are able to handle whole
1330 commercial and residential buildings, independent of it being HVAC or a BMS application.
1331
1332 EN 50090-5 which describes different PHY layers secures that all different needs from existing and
1333 new Buildings will be fulfilled
1334
1335 KNX standardizes the layers 1 to 7 of the OSI reference model. It additionally standardizes a rich
1336 set of application specifications to allow for a single and common information exchange.

1337 4.2.7.1 Communication security

1338 The KNX communication security provides for
1339 Authentication
1340 Confidentiality
1341 For this, AES-128 encryption is again used and the data integrity is controlled over an HMAC-MD5
1342 signature.
1343
1344 The communication security is situated in the Application Interface Layer, making it available to all
1345 services for runtime and for configuration, yet not requiring explicit support on Retransmitters or
1346 Couplers, which would be a security risk.
1347
1348 The configuration uses Diffie-Hellman key exchange supported in the multiple Configuration
1349 Modes. This keeps the security transparent to the application and maintains the Interworking.

1350 4.2.7.2 Proposed EN 50090 developments

1351 Create a neutral interface between Smart Grid and HBES (Smart Grid demand side) within CLC
1352 TC205 WG18

37
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1353 4.2.7.3 Stack architecture

1354
Metering
LTE-Mode
applications and …

S-Mode
configuration Energy Management Ctrl-Mode
modes Shutters and Blinds
PB-Mode
Lighting
Runtime Configuration

Group Objects Interface Objects

Application Layer
common stack Security

Transport Layer

Network Layer

SEC
communication
media PL TP RF IP

SEC
1355
1356 Figure 7: EN 50090 protocol stack

1357 4.2.7.4 The EN 50090 Standard Landscape

38
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1358
1359 Figure 8: EN 50090 HBES Standards Landscape

1360 4.2.8 EN 14908 family

1361
1362 EN 14908 is a family of standards for control networking that is widely used in smart grid, smart
1363 building, and smart grid applications.
1364
1365 The full suite of worldwide, open standards includes the following associated standards:
1366
1367 ISO/IEC 14908-1, which specifies a multi-purpose control network protocol stack optimized
1368 for smart grid, smart building, and smart city applications
1369 ISO/IEC 14908-2, which specifies a free-topology twisted-pair channel for networked
1370 control systems in local area control networks and is used in conjunction with ISO 14908-1
1371 ISO/IEC 14908-3, which specifies a control network Power Line (PL) channel that operates
1372 in the EN 50065-1 CENELEC C-Band and serves as a companion document to ISO 14908-
1373 1
1374 ISO/IEC 14908-4 specifies the transporting of the control network protocol packets for
1375 commercial local area control networks over Internet Protocol (IP) networks and is used in
1376 conjunction with ISO 14908-1
1377 ETSI TS 103 908, which specifies a high-performance narrow band power line channel for
1378 control networking in the smart grid that operates in the EN 50065-1 CENELEC for use with
1379 ISO 14908-1
1380 US standards ANSI 709.1, .2, .3. and .4
1381 EU standards EN 14908-1, -2, -3, -4, -5 and -6

1382 China standards GB/Z 20177.1

39
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1383 US standard IEEE 1473-L

1384 US standard SEMI E54

1385
1386 EN 14908 family standardizes layers 1 to 7 of the OSI reference model as shown in the figure
1387 below. It includes standard definitions for a number of physical layer channels optimized for
1388 specific control networking applications such as smart grid and smart buildings, and includes a rich
1389 set of data models to promote interoperable devices in smart building, smart city and smart grid
1390 applications.
1391

1392
1393 Figure 9: EN 14908 protocol stack

1394 4.3 SCADA substation protocols

1395 4.3.1 IEC 60870

1396 IEC 60870-5 refers to a collection of standards produced by the International Electrotechnical
1397 Commission (IEC) which provides an open standard for the transmission of SCADA telemetry
1398 control and information. The standard provides a detailed functional description for remote control
1399 equipment and systems for controlling geographically widespread processes, in other words for
1400 SCADA systems.
1401 When the IEC 60870-5 set of standards was initially completed in 1995 with the publication of the
1402 IEC 870-5-101 profile, it covered only transmission over relatively low bandwidth bit-serial
1403 communication circuits. With the increasingly widespread use of network communications
1404 technology, IEC 60870-5 now also provides for communications over networks using the TCP/IP
1405 protocol suite.

40
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1406 The IEC 60870 standard is structured in a hierarchical manner, comprising parts, sessions and
1407 companion standards. The companion standards extend the definition provided by the main parts
1408 of the standard by adding specific information objects for the field of application.
1409 The parts of IEC 60870 are as follows:
1410
1411 a. Main Part
1412 IEC 60870-1, General Considerations
1413 IEC 60870-2, Operating Conditions
1414 IEC 60870-3, Interfaces (electrical characteristics)
1415 IEC 60870-4, Performance Requirements
1416 IEC 60870-5, Transmission Protocols
1417 IEC 60870-6, Telecontrol Protocols Compatible With ISO and ITU-T Recommendations
1418
1419 b. Sections of IEC 60870-5
1420 IEC 60870-5-1, Transmission Frame Formats
1421 IEC 60870-5-2, Link Transmission Procedures
1422 IEC 60870-5-3, General Structure of Application Data
1423 IEC 60870-5-4, Definition and Coding of Application Information Elements
1424 IEC 60870-5-5, Basic Application Functions
1425
1426 c. Companion Standards of IEC 60870-5
1427 IEC 60870-5-101, Companion Standard for Basic Telecontrol Tasks
1428 IEC 60870-5-102, Companion Standard for Transmission of Integrated Totals
1429 IEC 60870-5-103, Companion Standard for Protection Communication
1430 IEC 60870-5-104, Network Access using Standard Transport Profiles
1431
1432 The IEC 60870-5-104 defines the transport of IEC 60870-5 application messages over networks.

1433 4.3.2 IEC 60870-5-101 System topology

1434 IEC 60870-5-101, or T101, supports point-to-point and multidrop communication links carrying bit-
1435 serial low-bandwidth data communications. It provides the choice of using balanced or unbalanced
1436 communication at the link level.
1437 With unbalanced communication, only the master can initiate a communication by transmitting
1438 primary frames. All communications are initiated by master station requests, which poll for user
1439 data if available.
1440 Balanced communication is available, but it is limited to point-to-point links only.
1441 Therefore whilst T101 can support unsolicited messages from a slave, it cannot do so for a
1442 multidrop topology and must employ a cyclic polling scheme to interrogate the secondary stations.
1443 A ‘monitor direction’ and a ‘control direction’ are also defined: monitored data such as analog
1444 values from the field are sent in the monitoring direction, and commands are sent in the control
1445 direction. If a station both sends monitored data and sends commands, it is acting both as a
1446 controlled and a controlling station: this last is defined as dual-mode operation. It is accommodated
1447 by the protocol, but requires the use of originator addresses in the ASDU4.

1448 4.3.3 IEC 60870-5-101 Message structure

1449 The message structure under IEC 60870-5-101 is composed by a data link layer frame carrying
1450 link address and control information, a flag to indicate if Class 1 data (highest priority information)
1451 is available, and optional application data. Each frame can carry a maximum of one application
1452 service data unit, or ASDU. The following figure shows the data link frame structure, and the
1453 structure of the application layer ASDU carried by it.

4 “Practical Modern SCADA Protocols” – Gordon Clarke and Deon Reynders

41
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1454

1455
1456
1457 Figure 10: Message Structure of IEC 60870-5-1015

1458 4.3.4 IEC 60870-5-101 Addressing

1459 Under IEC 60870-5-101 addressing is provided the link at the application level. The link address
1460 field may be 1 or 2 octets for unbalanced and 0, 1 or 2 octets for balanced communications. As
1461 balanced communications are point-to-point the link address is redundant, but may be included for
1462 security. The link address FF or FFFF is defined as a broadcast address, and may be used to
1463 address all stations at the link level.
1464
1465 At the application level, the ASDU contains a 1 or 2 octet common address. This is defined as the
1466 address of the controlling station in the ‘control direction’, and the address of the controlled station
1467 in the ‘monitoring direction’. The common address of the ASDU combined with the information
1468 object address contained within the data itself combine to make the unique address for each data
1469 element.
1470
1471 There may be more than one logical or common address per device. As for the link level, the
1472 address FF or FFFF is defined as a broadcast address. Therefore to send a broadcast message it
1473 is necessary to include this address in both the data link and application address fields.

1474 4.3.5 IEC 60870-5-104 Networked version

1475 Under IEC 60870-5 there are two different methods of transporting messages. The first is IEC
1476 60870-5-101, or T101, which provides for bit-serial communications over low-bandwidth
1477 communications channels.
1478
1479 The second method was defined with the release of the IEC 60870-5-104, or T104 profile. In this
1480 protocol the lower levels of the protocol have been completely replaced by the TCP and IP

5 “Practical Modern SCADA Protocols” – Gordon Clarke and Deon Reynders

42
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1481 transport and network protocols. These protocols provide the transport of the application service
1482 data units (ASDUs) over corporate local area networks and wide area networks.
1483 The structure of the protocol or ‘protocol stack’ is shown in Table 4.
1484
1485 Table 4: Protocol Stack IEC 60870-5-1046

1486
1487
1488 Whereas T101 provides full definition of the protocol stack right down to the physical level, this is
1489 not provided under T104 as existing and varied physical and link layer operations are employed.

1490 4.3.6 IEC 60870-4-101 Application data objects

1491 IEC 60870-5 includes a set of information objects that are suited to both general SCADA
1492 applications and electrical system applications in particular. Each different type of data has a
1493 unique type identification number. Only one type of data is included in any one ASDU, and the type
1494 identification is the first field in the ASDU.
1495
1496 The information object types are grouped by direction and by type of information, as follows:
1497
1498 Table 5: Information Object Type Groups

1499

1500 4.4 Wireless Access & Wide Area Technologies

1501 4.4.1 Overview of GSM Family of Cellular Communication Systems

1502 4.4.1.1 GSM family of cellular communication systems – overview

1503 GSM technology has been in development since 1987. The evolution of GSM standard-based
1504 mobile communication systems will be consistent globally, and will follow a clear path from the
1505 second and third generation of mobile networks that is widely available today to LTE technology
1506 [Figure 10].

6 “Practical Modern SCADA Protocols” – Gordon Clarke and Deon Reynders

43
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1507

1508
1509 Figure 10: Evolution of 3GPP Family of Mobile Broadband Technologies
1510 Note: HSPA+ peak theoretical data rate reaches up to 42 Mbps when using single carrier with
1511 QAM 64 and 2x2MIMO
1512
1513 Table 6: Technical Characteristics of Different Generations of Mobile Technology
Peak Data rate* (downlink) Latency/Round-trip
time
2G GSM 9.6kbps 150-200ms
GPRS 40kbps >500ms

EDGE 236.8kbps 100-200ms

EDGE Evolution has downlink speeds
of up to 1.3Mbps in the downlink and
653Kbps in the uplink
3G UMTS 384kbps 200-250ms
HSPA 14.4Mbps 50-100ms

HSPA+ 28Mbps in Rel-7 28+ms

42Mbps in Rel-8
84Mbps in Rel-9
168Mbps in 20MHz in Rel-10
336+Mbps in 40 MHz in Rel-11
4G LTE 170Mbps in Rel-8 and Rel-9 5-10ms

LTE- >300 Mbps by aggregating multiple 20 5-10ms

Advanced MHz carriers in Rel-10
>1Gbps in 80 MHz and 4x4 MIMO in
Rel-11
1514
1515 Note: Theoretical maximum data rates are quoted in this table – achievable throughput tends to
1516 1/5th to 1/7th of this theoretical maximum
1517 Source: GSMA
1518

44
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1519
1520 Figure 11: GSMA family of technologies development to date

1521 4.4.2 GPRS / EDGE (General packet radio service / Enhanced Data rates for Global
1522 Evolution
1523
1524 Technology Overview

1525 GPRS (General packet radio service) is a second generation (2G) wireless broadband technology,
1526 originally standardized by the European Telecommunications Standards Institute (ETSI), and
1527 currently maintained by the Third Generation Partnership Project (3GPP) industry trade group.
1528 GPRS (Release 97) and EDGE (Release 98) are largely specified in the GSM EDGE Radio
1529 Access Network (GERAN) group of 3GPP.
1530
1531 Based on specifications in Release 97, GPRS typically reaches speeds of 40Kbps in the downlink
1532 and 14Kbps in the uplink by aggregating GSM time slots into one bearer. Enhancements in
1533 Releases R’98 and R’99 meant that GPRS could theoretically reach downlink speeds of up to
1534 171Kbps.
1535
1536 In practice, GPRS is a best-effort service, which means that throughput and latency can be
1537 variable depending on the number of other users sharing the service concurrently.
1538
1539 EDGE (Enhanced Data rates for Global Evolution) or Enhanced GRPS is the next advance in GSM
1540 radio access technology. EDGE re-uses the existing GSM spectrum, with a new modulation
1541 technique yielding a three-fold increase in bit rate (8PSK replacing GMSK) and new channel
1542 coding for spectral efficiency.
1543
1544 On-going standards work in 3GPP has delivered EDGE Evolution as part of Release 7, designed
1545 to complement high-speed packet access (HSPA).
1546
1547 EDGE Evolution, resulting from the HUGE and RED HOT work items, has:
1548 - Improved spectral efficiency with reduced latencies down to 100ms
1549 - Increased throughput speeds to 1.3Mbps in the downlink and 653Kbps in the uplink
1550

45
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1551 4.4.3 UMTS (Universal Mobile Telecommunications System)

1552
1553 Technology Overview

1554 UMTS is an umbrella term for the third generation (3G) radio technologies developed within 3GPP.
1555 The 3G radio technologies include:
1556 - W-CDMA (Wideband Code Division Multiple Access), the radio technology, which is a part
1557 of the ITU IMT-2000 family of 3G Standards, and
1558 - HSPA (High-Speed Packet Access), the radio technology largely covered by the Radio
1559 Access Network (RAN) group of 3GPP.
1560 - HSPA+ (Evolved High-Speed Packet Access), the radio technology first defined in 3GPP’s
1561 Release 7.
1562
1563 W-CDMA was specified in Release 99 and Release 4 of the specifications. High Speed Packet
1564 Access (HSPA) was introduced in Releases 5 (Downlink) and 6 (Uplink) giving substantially
1565 greater bit rates and improving packet-switched applications.
1566
1567 HSPA improvements in UMTS spectrum efficiency are achieved through:
1568
1569 • New modulation (16QAM) techniques
1570 • Reduced radio frame lengths
1571 • New functionalities within radio networks (including re-transmissions between NodeB and
1572 the Radio Network Controller)
1573 • Consequently, throughput is increased and latency is reduced (down to 100ms and 50ms
1574 for HSDPA and HSUPA respectively).
1575
1576 HSPA+ a natural evolution of 3G networks, much like HSPA was an evolution of UMTS and EDGE
1577 was an evolution of GSM. HSPA+ generally only requires a software upgrade to the infrastructure
1578 as well as increased backhaul and transport capabilities in order to support the significantly higher
1579 data rates offered by the technology. For certain legacy systems new hardware may be required to
1580 make the transition, although this requirement has not stopped some operators from moving
1581 forward with HSPA+. In other situations operators may upgrade their infrastructure as part of the
1582 natural hardware refreshment process or to take advantage of more power efficient and smaller
1583 form factor solutions, at which point only new software would be required for HSPA+.
1584
1585 HSPA+ introduces the following new functionalities for HSPA:
1586
1587 - Release 7 added multiple input/ multiple output (MIMO) antenna capability and 16QAM
1588 (Uplink)/ 64QAM (Downlink) modulation. 64QAM (Quadrature Modulation Scheme) enables
1589 theoretical peak data rates in the downlink direction of up to 21Mbps. This compares with a
1590 peak data rate of 14.4Mbps with HSPA.
1591
1592 The data capacity of HSPA+ in Rel-7 is double of HSPA Rel-6, which is an important
1593 improvement for Smart Grid applications.
1594
1595 MIMO (Multiple Input, Multiple Output) enables theoretical peak data rates of up to 28Mbps
1596 in a single 2x5MHz radio channel. MIMO uses two antennas at the cell site (transmitter)
1597 and two antennas at the mobile terminal (receiver) to send data bits in parallel streams
1598 down two separate transmission paths. MIMO is a key feature in all next-generation
1599 wireless technologies, including LTE and LTE Advanced.
1600

46
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1601 HSPA+ is backwards compatible with HSPA, meaning that MIMO-enabled HSPA+ devices
1602 work in an HSPA network and that legacy UMTS/HSPA devices work in a MIMO-enabled
1603 HSPA+ network.
1604
1605 - Enhanced CELL_FACH significantly increases signalling load and improves the capacity
1606 for bursty traffic.
1607 - Coupled with improvements in the radio access network for continuous packet connectivity,
1608 HSPA+ allows Uplink speeds of 11Mbps and Downlink speeds of 42Mbps within the
1609 Release 8 time frame.
1610
1611 Further improvements were introduced in Dual-cell or Dual-carrier HSPA (DC-HSPA). Dual cell or
1612 Dual carrier HSPA was defined in 3GPP Release 8, specifying carrier aggregation for increased
1613 spectrum efficiency and load balancing across the carriers.
1614
1615 - DC-HSPA+ (Rel-8) can double the capacity for bursty applications, which includes most
1616 Smart Grid applications.
1617 - Release 7, MIMO deployments can benefit from the DC-HSDPA functionality as defined in
1618 Release 8.
1619 - Release 8, DC-HSPDA operates on adjacent carriers
1620 - Release 9, paired cells can operate on two different frequency bands, possible to use DC-
1621 HSDPA in combination with MIMO. In Release 9, it will also be possible to implement DC-
1622 HSPA in the uplink, thus doubling the peak data rate to 11Mbps or 23Mbps with the
1623 addition of 16QAM.
1624
1625 Release 9 also supports an innovative feature called Supplemental Downlink, which
1626 combines unpaired spectrum (e.g. TDD) with the downlink of paired spectrum, and
1627 significantly increases the downlink capacity.
1628
1629 - HSPA+ Rel-10, which is already standardized, supports aggregation of up to 4 carriers
1630 enabling 20 MHz deployments. HSPA+ through its many features allows operators
1631 leverage all of their spectrum resources.
1632
1633 HSPA+ Advanced consists of enhancements being defined in Release 11 and beyond, introducing
1634 a range of new performance improvements. These enhancements can be divided into five broad
1635 areas:
1636 1. Evolving Multicarrier to utilize all available spectrum assets;
1637 2. Introducing features such as MultiFlow to exploit uneven network loading;
1638 3. Optimizing HetNets to get even higher performance from small cells;
1639 4. Further leveraging advanced antenna techniques;
1640 5. Efficiently connecting the next explosion of interconnected, low-traffic and bursty machine-
1641 to-machine devices, which are forecast to reach billions in the next 5-10 years, and
1642 supporting the continued growth of smartphones.
1643
1644 Users of HSPA+ networks would benefit from the backwards compatibility of HSPA+ with
1645 UMTS/HSPA as well as the large ecosystem of device and chipset suppliers that are available.
1646 LTE and HSPA+ are considered to be complementary technologies and an operator’s initial
1647 support of one technology will not come at the expense of their support for the other technology.
1648 Many of the operators who have already deployed HSPA+ are also in the process of deploying
1649 LTE. Still other operators may opt to deploy LTE first and then upgrade their HSPA networks to
1650 HSPA+ to augment the capabilities and coverage of their LTE network. LTE is best suited for new
1651 and wider bandwidth (10 MHz or more) as well as TDD spectrum. HSPA+, on the other hand, is
1652 well suited for the existing spectrum or new spectrum with 5MHz bandwidths.
1653

47
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1654 The HSPA/HSPA+ system development have benefitted from large-scale adoption worldwide.
1655 Following an explosive rise in demand for smartphones, connected tablets and Mobile Broadband
1656 dongles across the globe, there are now more than 590 million HSPA Mobile Broadband
1657 connections worldwide, making it the fastest growing wireless technology ever. Mobile Broadband
1658 adoption in its first six years was ten times faster than the take up of 2G mobile phones when they
1659 were first introduced in the early 1990s. The global mobile industry is now connecting 19 million
1660 new HSPA devices each month and is on course to reach one billion HSPA connections by the
1661 end of 2012. HSPA Mobile Broadband networks have now been deployed in 135 countries.
1662
1663 Over the next five years, Rethink Technology Research forecasts that mobile operators will invest
1664 almost US$100 billion in HSPA, HSPA+ and next-generation LTE networks, which offer peak
1665 download speeds of up to 100Mbps – ten times faster than the average wired broadband
1666 connection today.

1667 4.4.3.1 Mobile Network Resilience

1668 Mobile networks are built to deliver ‘’five nines’ availability: the networks are up for 99.999% of the
1669 time, which translates into 38 minutes/year downtime.
1670
1671 Equipment is deployed with ‘N+1’ or ‘1+1’ redundancy and has stand-by powering available in
1672 case of power outage. For every piece of equipment in the network there is always a ‘spare’ that is
1673 in ‘warm stand-by’, so that if a fault occurs, the stand by equipment takes over. In reality, both
1674 pieces of equipment are active and load balancing is taking place between the two. This means
1675 that there is always spare capacity in the network elements since both have to run at low efficiency
1676 so they can handle the calls/sessions the other is managing if there is a failure.
1677
1678 Links between network equipment are usually installed with:-
1679 - Sufficient capacity to handle busy hour traffic peaks and unexpected surges in demand
1680 - Redundancy (often including geo-redundancy) to offset the risk of link breakage disrupting
1681 service.
1682
1683 Critical network elements are installed in geo-redundant locations. If one site is attacked, another
1684 site has all information stored and can take up service.
1685
1686 All mobile networks have a Network Operations Centre (NOC) where all faults and outages are
1687 reported and necessary repairs are coordinated from.

1688 4.4.3.2 Embedded SIM

1689 The UICC (Universal Integrated Circuit Card) is the smart card used in mobile devices in GSM and
1690 UMTS networks. In a GSM network, the UICC contains a Subscriber Identity Module (SIM)
1691 application and in a UMTS network it is the Universal Subscriber Identity Module USIM application.
1692
1693 The Embedded SIM is a separately identifiable hardware component (tamper-resistant
1694 microprocessor with secure memory), which is installed in a device at manufacture, replacing the
1695 need for a traditional SIM. It is not intended to be removed or replaced, and it has functionality
1696 allowing its secure remote management including loading/reloading of mobile operator credentials
1697 and applications. It is supported by a set of secure interfaces and standards that allow operator
1698 credentials to be transported securely from the Operator to the Embedded SIM, thus providing the
1699 integrity and trust necessary to protect users and operators during the transport and provisioning of
1700 sensitive data. This is a fundamental change to current models of hard coded SIM applications.
1701
1702 Embedded SIM allows selection of a mobile operator and country to happen independently of
1703 distribution channel, which is a significant benefit to manufacturers through the reduction of stock

48
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1704 items needed. It enables subscribers to switch operator during product life cycle, which for many
1705 smart grid products is in excess of 10-15 years. The Embedded SIM also permits removal of MNO
1706 credentials from SIM card (termination) with re-use of device/eUICC on the same or another
1707 network.
1708
1709 Embedded SIM will have the potential to support the following major business use cases relevant
1710 to the smart grid:
1711 a. Provisioning of multiple Machine subscriptions, where an Service Provider sets-up
1712 subscriptions for a number of connected data devices to start telecommunication
1713 services with a Network Operator;
1714 b. Subscription change, where a subscriber changes the subscription for a device to stop
1715 services with the current Mobile Network Operator and start services with a new Mobile
1716 Network Operator;
1717 c. Stop subscription remotely, where a subscriber stops services with the current MNO
1718 d. Transfer subscription, where a subscription is transferred between devices
1719
1720 The standardization of the Embedded SIM is taking place at ETSI SCP (Smart Card Platform)
1721 technical committee (http://portal.etsi.org/scp), which is currently defining the requirements.
1722
1723 It is worth noting that the Embedded SIM preserves the traditional advantages of the SIM/UICC
1724 card platform, some of which may be of particular interest in the smart grid context and especially
1725 in smart metering:
1726 1. A programmable tamper-resistant microprocessor able to support multiple applications,
1727 which could be used as the security module in the gateway of a smart metering systems to
1728 comply with the requirements of the BSI Protection Profile for Smart Meter Gateway issued
1729 in Germany.
1730 2. An standardized programming environment (JavaCard virtual machine) and Application
1731 Programming Interface (Card Application Toolkit) enabling the interoperable downloading
1732 and remote management of third-party applications
1733 3. Support of Global Platform specifications, which enable the following features:
1734 a. Provisioning and management of third party applications in confidentiality from the
1735 communication service provider, where desired
1736 b. Ability for each third party application to run in its own "Security Domain", providing
1737 firewall protection for its private information
1738 c. Ability for each third party application to establish a secure channel with its service
1739 provider independently from the other applications.
1740
1741 The combination of these features may assist in resolving the privacy issues associated with smart
1742 metering as depicted in the following figure, where raw energy data are processed independently
1743 in the applications Security Domains of the embedded SIM to extract only the information of
1744 interest to their service providers:
1745

49
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1746
1747 Figure 12: Privacy issues associated with smart metering

1748 4.4.4 Long Term Evolution (LTE) for Smart grid

1749 4.4.4.1 Overview of LTE

1750 LTE (Long Term Evolution) is the next generation wireless broadband technology developed and
1751 standardized by the Third Generation Partnership Project (3GPP) industry trade group. LTE is the
1752 next step in a progression from GSM (2G), & UMTS (3G), providing increased data rates, reduced
1753 latency, and scalable bandwidth capacity. The air interface (originally specified in 3GPP Release
1754 8) combines OFDMA based modulation and multiple access scheme for the downlink, with SC-
1755 FDMA for the uplink. The available spectrum is split into a thousand or more of narrowband
1756 carriers, each carrying a part of the signal. In LTE, the innate spectral efficiency of OFDM is further
1757 enhanced with higher order modulation schemes (64QAM), sophisticated error correction
1758 schemes, and radio techniques such as MIMO and Beam Forming with up to four antennas per
1759 station enables greater throughput.
1760
1761 The combined effect of these radio interface features is significantly improved radio performance
1762 with up to 300 Mbit/s per 20 MHz of spectrum for the downlink and 75 Mbit/s per 20 MHz of
1763 spectrum for the uplink.
1764
1765 A key characteristic of LTE technology is that bandwidths are scalable from 1.4 MHz to 20 MHz.
1766 3GPP release 8 defines LTE bandwidths of 1.4, 3, 5,10, 15 and 20 MHz. OFDMA, the chosen
1767 transmission scheme for LTE ’s physical layer enables such bandwidth flexibility. Bandwidth
1768 scalability inherent in LTE provides a flexible and easy way to increase capacity on the air interface
1769 into the future to meet the demands of higher data throughputs, new applications and changes.
1770
1771 Table 7: 3GPP Long Term Evolution Requirements
Metric Description Requirement
Bandwidth Support of scalable 1.4,3,5,10,20MHz
bandwidth
Peak data rate Downlink 100Mbps
Uplink 50Mbps

Latency Transfer delay in RAN 5ms (one way)

Connection setup delay 100ms

50
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1772
1773 Every 3GPP LTE UE is required to support these afore mentioned bandwidths already from
1774 Release-8, therefore increasing system capacity in terms of cell throughput is as simple as scaling
1775 up the LTE allocated bandwidth. Where spectrum is shared with other systems such as GSM,
1776 scalability allows for progressive spectrum allocation, conserving capacity for legacy systems until
1777 such time as the extra bandwidth is required for LTE applications.
1778
1779 Existing and Proposed LTE features
1780
1781  Dual-Stack IPv4/IPv6 support – IPv6 addressing is essential for large “machine
1782 communities”, and allows applications to work seamlessly across mobile and fixed
1783 broadband connections.
1784  Very low latency on user plane, control plane and scheduling (Short setup time & Short
1785 transfer delay, Short TTI,) essential for Grid applications handling thousands of devices
1786 within a cell. Previous generation technologies have slower radio reestablishment
1787 procedures and require larger overheads.
1788  Support of variable and scalable bandwidth (1.4, 3, 5, 10, 15 and 20 MHz) to effectively
1789 address capacity issues whilst optimizing spectrum utilization by legacy applications
1790 (GSM/UMTS). This is essential in enabling efficient and simple spectrum sharing, and
1791 allows a smooth migration, increasing bandwidth as the demands on the network
1792 increases (as the number of devices increases, or data requirements increase).
1793  Simple protocol architecture (Shared channel based, Packet Switched optimized with
1794 VoIP capability). Grid applications are data based; LTE is a network made especially to
1795 handle data as first priority.
1796  Simple Architecture (eNodeB as the only E-UTRAN node) – reduces system complexity,
1797 reduces latency and enhances scalability.
1798  Efficient Multicast/Broadcast. This is a desirable feature for future deployment of
1799 applications intended to make use of broadcast data.
1800  Support of Self-Organizing Network (SON) operation – reduces the need for OPEX
1801 intensive O&M tasks through automatic neighbour optimization and automatic interference
1802 management. This saves costs associated with manually configuring and tuning the
1803 network.
1804  Guard bands are part of the LTE specification, meaning that no extra consideration needs
1805 to be taken in calculating spectrum requirements. LTE can be put right next to GSM/HSPA
1806 without any extra guard band required.
1807  Increased spectrum efficiency in DL from 15bps/Hz to 30bps/Hz. This provides capacity
1808 expansion into the future to meet the needs of new applications and faster downlink data
1809 transfer rates.
1810  Support for non-contiguous bandwidth scalability, allowing aggregation of non-adjacent
1811 bandwidth allocations (increasing capacity). This provides greater flexibility for capacity
1812 expansion into the future without the need to secure contiguous spectrum.
1813  Improved support for heterogeneous deployments and relaying, reducing the cost of
1814 network coverage expansion.
1815
1816 In addition to the technological and business reasons for selecting it, LTE also benefits from its
1817 foundation as a global standard. With the selection of LTE, the following benefits are guaranteed:
1818
1819  Backwards compatibility: Future releases maintain compatibility with existing releases, so
1820 that old equipment is not made obsolete.
1821  Robust evolution: LTE is constantly being improved and operators are constantly
1822 upgrading their networks. It is envisaged that LTE radio access technology could be
1823 evolved for the coming 20 years.

51
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1824  Large ecosystem: The reliance on standardized solutions ensures that there is healthy
1825 competition and a large menu of products available.
1826  Standardization of not only the radio technology, but of a coherent system as a whole
1827 including the core network, services aspects, security aspects, and management aspects.
1828  High bandwidth, low latency, high reliability, QoS, secure ecosystem,

1829 4.4.4.2 LTE and Wide Area Networks

1830 LTE is primarily a wide area technology. It is developed for data communications (voice is
1831 considered just another type of data). It is being considered extensively for machine-to-machine
1832 communications. As it is a next generation technology, meaning that 3GPP has a considerable
1833 base of previous knowledge to work with in developing wireless networks. Much of this worked
1834 focused not only on specifying a system with improved performance, but also on standards to
1835 reduce the total cost of ownership. Within 3GPP many of the standardized technologies such as
1836 SON or Minimization of Drive Tests are focused on simplifying the deployment and maintenance of
1837 the network.
1838
1839 3GPP also allows for various business types of arrangements that may reduce costs such a
1840 sharing of the network between multiple operators or virtual network operators.
1841
1842 Since LTE is global standard, this requires a large amount of flexibility. LTE must be able to be
1843 deployed within various national frequency band plans. It must be able to coexist with other
1844 technologies, and conform to various nation regulations. In Release 10, LTE was defined for 25
1845 FDD bands and 11 TDD bands with new bands being added all the time. In addition to individual
1846 bands, 3GPP has the concept of carrier aggregation, which allows different bands to be
1847 aggregated to act as a wideband carrier.
1848
1849 LTE is required to exist in many radio environments such as rural areas, urban canyons, subways
1850 etc. For this reason, 3GPP allows for a variety of sizes of cells ranging from macro cells that cover
1851 100 square miles to micro cells, pico cells, and recently home eNodeb’s that are intended to work
1852 in residential or hotspot type of environments. LTE is specified to fullfil the full performance
1853 requirements in cells with 5 km radius, with slight performance degradations (reasonable
1854 performance) in cells with 30 km radius and should not preclude (acceptable performance) cells
1855 with 100 km radius. 100 km radius translates to around 12000 square miles while 30 km radius
1856 covers around 1100 square miles.
1857
1858 Even when LTE devices are not mobile, the radio environment can vary wildly over time. LTE is
1859 designed to make optimal use of the available micro cells and macro cells to provide throughput
1860 and increase reliability.
1861
1862 Although LTE was designed for data communications, it was realized that not all data
1863 communications are the same. LTE allows for different QoS characteristics to be associated with
1864 different data streams. These characteristics include aspects such as:
1865  Guaranteed bit rate or not
1866  Allocation retention priority
1867  Priority
1868  Bit rate
1869  Delay
1870  Maximum bit loss
1871
1872 LTE Release 8 supported bit rates of 100Mbit/sec, latencies in - the order of 10ms on the radio
1873 interface, and maximum bit error rates as low as10^-5. These numbers are constantly improving
1874 with each release.
1875

52
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1876 Support for these parameters is integrated into the system and extends from the terminals through
1877 the radio network and through the core network. In addition, 3GPP is working on further optimizing
1878 the system to cater to machine-to-machine type characteristics such as bursty traffic, infrequent
1879 message sending and greater uplink traffic than downlink.
1880
1881 Optimizations will improve the efficiency of the network; whilst maintaining backwards
1882 compatibility. This means that whatever changes are made to improve efficiency or improve
1883 performance will not affect the ability of existing devices and applications to continue to work.
1884 3GPP Release 10 addressed Overload Control mechanisms to protect mobile networks from data
1885 signaling congestion and overload, e.g. the distributed ability to reject connection requests from
1886 delay-tolerant services to maintain critical services. Whereas in Release 10 the focus was in the
1887 core network overload control, in Release 11 3GPP is working on overload control of the radio
1888 network and Random Access Channel in particular.
1889
1890 One specific expectation with machine-to-machine type of devices is that there will be a large
1891 number of devices. LTE devices are dual stack (ipv4/ipv6) to ensure that growth is not limited by
1892 IP addresses. Other identifiers are not seen as an immediate problem, however 3GPP is also
1893 working to ensure that there are no limitations in that area.3GPP Release 11 is currently working
1894 on System improvement for Machine Type Communication focusing on reachability aspects e.g.
1895 addressing and identifiers, Device triggering and architectural enhancements for machines &
1896 meters.
1897
1898 Another area were LTE has a strong heritage is in security. The need for security is a fundamental
1899 requirement on LTE systems. 3GPP ensures that the systems are not only secure, but that
1900 backup algorithms exist in case the primary algorithms are ever compromised.

1901 4.4.4.3 LTE and Field Area Networks

1902 LTE is designed to work in licensed bands. This will in many cases mean that it is more reliable
1903 than networks deployed on the ISM band. The 3GPP standard certainly allows for small cell sites
1904 and many such products exist and are currently deployed today.
1905
1906 However, another option is to use a commercial LTE network and thus completely eliminate the
1907 need for a field area network. LTE may of course also be deployed in dedicated bands owned by
1908 the utilities. 3GPP can consider standardizing additional bands if required. 3GPP will not however
1909 extend the technology to the ISM bands.
1910
1911 It should be noted that LTE is ideally suited to scenarios where large populations of devices
1912 require concurrent data communication within a sector. This is a key requirement during scenarios
1913 such as soft starting a network after a blackout (remotely disconnecting a large volume of
1914 residences and then turning them on in smaller groups so as not to overload the systems with high
1915 start-up current), suburb-by-suburb off-peak tariff control, street light control, distributed generation
1916 and so on.
1917
1918 Typically, the devices on the network are fixed geographically and spend most of their time in an
1919 idle mode. When a traffic event occurs (initiated either by the terminal device or a system external
1920 to the LTE network), the devices attach to the network using standard 3GPP LTE protocols, and
1921 are then able to send or receive data, depending on the application and traffic case.
1922
1923 In general, the devices do not move, and have no need to use the various mobility management
1924 functions inherent in the LTE system. However, devices that are situated in marginal coverage
1925 areas (towards the edge of a coverage cell) will be able to signal via different sectors as the need
1926 arises.
1927

53
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1928 One of the areas currently being investigated by 3GPP is the specification of low cost LTE devices.
1929 These are devices or modules, which are suitable for low demand applications and achieve a
1930 lower price point than full-fledged LTE modules.

1931 4.4.4.4 LTE and Premises Networks

1932 LTE has two methods of addressing premises networks:
1933 • Home ENodeBs (femtocells) are small base stations that are specified to connect to the
1934 cellular network over the customer’s broadband connection. These use LTE (or HSPA)
1935 • WLAN integration allows for cellular traffic to be tunneled over the customer’s broadband
1936 connection. This requires devices that are Wi-Fi capable.
1937
1938 For these two options, there are various possibilities with respect to steering traffic, offloading
1939 traffic, and access/visibility of local network resources.
1940
1941 These two methods have been specified within 3GPP. The primary advantage of these methods
1942 over traditional Wi-Fi only is that it provides the mobility, security, management, QoS capabilities
1943 inherent in 3GPP networks.
1944
1945 A special case within this scenario is the Plug in Electric Vehicle (PEV). PEVs are expected to
1946 sometimes be part of the premises network, but also require mobility. LTE is an obvious candidate
1947 for such mobility. With a LTE HeNB or integrated Wi-Fi, then the same applications that work in
1948 the premises continue to work while on the road.

1949 4.4.5 Wireline access technologies

1950 4.4.5.1 Digital Subscriber Lines, xDSL

1951 For the past twenty years, digital subscriber lines technologies have been adopted worldwide with
1952 a high penetration by the operators and users. The main driver of its success is the constant
1953 increase of the bit rate over existing copper wires, which opens the doors to numerous new
1954 services like high speed internet and IPTV (Internet Protocol Television). This highlighted the
1955 importance of guaranteed rate and almost error free transmission. Accompanying this trend to
1956 higher and more stable bit rates, the ITU-T has generated a series of Recommendations dedicated
1957 to DSL systems and updated them regularly.
1958
1959 Table 8: ITU-T Recommendations on DSL systems
(S)HDSL HDSL SHDSL
G.991.1 G.991.2
ADSL ADSL Splitterless ADSL ADSL2 Splitterless ADSL2 ADSL2plus
G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
VDSL VDSL VDSL2 VDSL2 with
G.993.1 G.993.2 Vectoring
G.993.5
Common Handshake Overview DSL Test Single ended line
aspects G.994.1 systems procedures testing
G.995.1/G.sup50 G.996.1 G.996.2
Physical layer Multi-pair bonding Interfaces Improved impulse
management for G.998.1/2/3 PHY / Link noise protection for
DSL Layer DSL transceivers
G.997.1 G.999.1 G.998.4
1960

54
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

1961 The first series of ITU-T Recommendations, G.991.x, on DSL targets business services. They are
1962 characterized by single carrier baseband system using the same frequencies in upstream and
1963 downstream directions. They provide symmetric services up to 6 Mbit/s with very low latency.
1964 The second series of ITU-T Recommendations, G.992.x, targets residential services from the
1965 central office. Using a multi-carrier modulation and frequency division duplexing, they provide
1966 asymmetric services up to 16 Mbit/s in the downstream direction and 800 Kbit/s to the central
1967 office. The variants ITU-T G.992.1 (ADSL), ITU-T G.992.3 (ADSL2), and ITU-T G.992.5
1968 (ADSL2plus) are the most widely deployed DSL systems in the world.
1969 The third series of ITU-T Recommendations, G.993.x, is intended for residential and business
1970 services from the cabinet. The first variant is ITU-T G.993.1 (VDSL). It was quickly followed by the
1971 second variant, ITU-T G.993.2 (VDSL2). The latter is now the most deployed one. ITU-T G.993.2
1972 is a multi-carrier system with a frequency division multiplexing similar to ITU-T G.992.3, but using a
1973 wider frequency band to provide bit rates up to 100 Mbit/s. VDSL2 has been designed to keep as
1974 many common functions with ADSL2. The third variant, ITU-T G.993.5, is an addition to VDSL2
1975 that permits to increase the rate or to extend the reach by using crosstalk cancellation between the
1976 pairs.
1977 On top of those three series, a set of Recommendations applicable to multiple ITU-T
1978 Recommendations were developed. For examples, ITU-T G.994.1 is a common protocol to
1979 negotiate between different xDSL technologies, ITU-T G.997.1 provides a common management
1980 interface to DSL technologies, ITU-T G.998.1/2/3 describes common bonding protocol for DSL,
1981 and ITU-T G.998.4 specifies a common retransmission technique for VDSL2 and ADSL2.

1982 4.4.5.2 Passive Optical Access Networks (PON)

1983 Optical fibre is capable of delivering bandwidth intensive integrated voice, data and video services
1984 at distances beyond 20 km in the access network. Various configurations can be imagined for the
1985 deployment of the optical fibre in the local access network. The most well known are Fibre to the
1986 Home (FTTH), Fibre to the Building (FTTB) and Fibre to the Curb (FTTC).
1987 Passive Optical Network (PON) is a technology viewed by many network operators as an attractive
1988 solution to minimize the amount of optical transceivers, central office terminations and fibre
1989 deployment. A PON is a point-to-multipoint optical network with no active element in the signal
1990 path from source to destination. The only interior elements used in a PON are passive optical
1991 components such as fibre, splices and splitters.
1992 The PON is completely passive and the maximum distance between the OLT and the ONU is
1993 typically limited to 20 km at nominal split ratios. However, there are also solutions that include
1994 deployment of active elements in the network structure (e.g., optical amplifiers) when it is
1995 necessary to achieve a longer reach (e.g., up to 60 km) or to reduce the number of CO sites (CO
1996 concentration), or to connect a larger number of users to a single OLT port (e.g., where higher
1997 power budget is required due to a higher split ratio). Such solutions are typically referred to as
1998 “long-reach PON”.
1999 A PON can be deployed in a FTTH (fiber to the home) architecture, where an ONU / ONT is
2000 provided at the subscriber's premises, or in FTTB (fiber to the building), FTTC (fiber to the curb) or
2001 FTTCab (fiber to the cabinet) architectures, depending on local demands. In the latter cases, the
2002 optical link is terminated at the ONU, and the last stretch to the subscriber's premises is typically
2003 deployed as part of the copper network using e.g., existing xDSL lines. Typically, Various types of
2004 xDSL technology are used, from the xDSL family of technologies, e.g., VDSL2 (Very high speed
2005 Digital Subscriber Line 2).
2006 Several versions of PON are at present specified in ITU-T: B-PON (G.983.x series), G-PON
2007 (G.984.x series), 10G-PON (G.987.x series). These three PON architectures have the same

55
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2008 infrastructure, design and installation. The main difference among the three solutions is related to
2009 downstream and upstream data rates, as shown in Table 9.

2010 Table 9: Downstream and upstream data rates for PON technologies
Type Downstream (max.) Upstream (max.)
Standard:1.2 Gbit/s Standard: 622Mbit/s
In service: 622 Mbit/s In service: 155 Mbit/s
ITU G.983.x series
(BPON)
2.5 Gbit/s Standard: 2.5 Gbit/s
ITU G.984.x series In service: 1.2 Gbit/s
(GPON)
10 Gbit/s 2.5 Gbit/s
ITU G.987.x series
(XG-PON1)
IEEE802.3ah (GEPON) 1 Gbit/s 1 Gbit/s
IEEE802.3av 10 Gbit/s 10 Gbit/s
(10G-EPON)
2011
2012 The ITU-T G.983.x series described PON systems based on ATM technology (A-PON / B-PON)
2013 and consisted of five Recommendations. The first described the base system, including the
2014 requirements, architecture, physical interfaces, and transmission convergence functions. The
2015 following four described features that were added subsequently.
2016
2017 The ITU-T G.984.x series described gigabit PON systems (G-PON), and consisted of seven
2018 Recommendations and one Supplement. The first four defined the base system, with one
2019 document each handling requirements, physical layer specifications, transmission convergence
2020 layer specifications, and management functions. The other four documents contained additional
2021 features and enhancements that arose later.
2022
2023 The ITU-T G.987.x series described 10 Gigabit capable Passive Optical Networks (XG-PON)
2024 systems, and consists of five Recommendations. The first provides defined terms and acronyms,
2025 and then the following three defines the base system, using the similar structure as for G-PON,
2026 with the exception of ONU management, which is handled by ITU-T G.988. The fifth document
2027 describes reach extension for XG-PON.
2028
2029 IEEE has defined Ethernet based PON solution (EPON). 802.3ah provides 1 Gbit/s and 802.3av
2030 10 Gbit/s bit rates. 802.3av supports simultaneous operation with 802.3ah by using separate
2031 wavelengths downstream and a shared wavelength upstream.
2032

2033 4.5 Core and metro networks overview

2034 4.5.1 Introduction

2035 4.5.2 IP MPLS

2036 To be completed in a subsequent release
2037

2038 4.5.3 MPLS-TP

2039 The MPLS Transport Profile (MPLS-TP) is an extension of the original MPLS protocol to optimize
2040 MPLS operation in transport (Layer 2) networks.

56
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2041
2042 A transport network provides efficient, reliable, qualitative and scalable connectivity over which
2043 multiple services can be supported, with a clear separation between the operations and
2044 management of the service layer from those of the transport layer. MPLS-TP is designed to satisfy
2045 transport network challenges like:
2046 • Providing efficient, reliable, long-standing, aggregated transport paths
2047 • Traffic Engineering for efficient utilization of the network resources
2048 • Efficient support of all kind of services
2049 • Transparent for service creation and modification
2050 • Effective and scalable bandwidth management, resiliency, and QoS
2051 • QoS with guaranteed bandwidth, controlled jitter and delay
2052 • Robust carrier-grade OAM
2053 • Protection and restoration mechanisms to provide high reliable services
2054 • Simple provisioning
2055 • Scalable to support millions of connections and global reach
2056 • Optimal interworking with upper and lower layer network technologies
2057
2058 MPLS-TP is a technology applicable for packet-switched transport networks and a profile of the
2059 extended MPLS toolkit defined by IETF. The IETF (bringing IP and MPLS packet expertise) and
2060 ITU-T (bringing transport expertise) together define the capabilities and ensure compatibility with
2061 the MPLS architecture and Mechanisms.
2062
2063 Much of the original MPLS design, architecture and mechanisms can be used in transport
2064 networks. However MPLS-TP is being extended in the following areas to fully support the
2065 transport’s requirements:
2066 1. Architecture:
2067  Both Operation Support System (OSS) based and dynamic control plane based
2068 provisioning or/and management
2069  Enhancements to work as pure Layer 2 technology without relying on IP functionality.
2070  Transmission of OAM messages in-band at all levels, i.e. along with the data traffic,
2071 subjecting them to the same treatment.
2072 2. Data-plane
2073  Support of bidirectional and co-routed connections
2074  MPLS path merging features such as multipoint-to-point and Penultimate Hop Popping
2075 (PHP) are disabled to ensure there is a unique label to identify a path end-to-end
2076 3. Resilience
2077  MPLS and GMPLS recovery mechanisms can be provisioned by the management plane.
2078  Support of linear protection mechanism with bi-directional operation to ensure co-routing of
2079 traffic in protection state.
2080  Support of hold-of timers to allow protection switching a several MPLS-TP levels.
2081  On-going work to optimize the protection operation of MPLS-TP in ring topologies.
2082 4. OAM
2083  Support of carrier grade transport network OAM mechanisms:
2084 Continuity Check, Connectivity Verification, Alarm notifications, Performance monitoring,
2085 Diagnostics
2086  OAM support at all MPLS-TP levels
2087 5. Management-plane and control-plane

57
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2088  Management-plane and control-plane can be used in conjunction or independently to

2089 provision paths and services
2090  Mechanisms are provided to provision and manage QoS and performance measurement
2091 parameters.
2092
2093 MPLS-TP provides transport services for various kinds of protocols, from IP, IP/MPLS to Ethernet,
2094 ATM, SDH, PDH, Frame Relay and others and enables therefore a migration from legacy transport
2095 network and protocols (e.g. circuit switched technologies like PDH and SDH). It can run over
2096 various transport infrastructures like Ethernet, OTN and SDH.
2097
2098 MPLS-TP supports point-to-point and point-to-multi point connectivity and can be used in access,
2099 aggregation and core networks scenarios providing a unified end-to-end solution.
2100 The traffic engineering, carrier-grade OAM and resilience mechanisms make MPLS-TP very
2101 suitable for applications, which require high reliability, low packet loss and low and deterministic
2102 delay/latency. The capability to differentiate between traffic classes allows to prioritize important
2103 traffic and to support different Service Level Agreements as needed.
2104

2105

2106 Figure 13: MPLS TP context

2107 General application areas for MPLS-TP are for mobile backhaul for cellular networks from the base
2108 stations to the core network, wireline aggregation networks and core router inter-connection and
2109 off-loading.
2110
2111 In the Smart Grid context MPLS-TP fits very well for sub-station to sub-station and sub-station to
2112 control centre communication including support for low latency applications and Ethernet services
2113 (e.g. teleprotection, IEC61850 GOOSE messages). Also high precision timing applications, using
2114 for example IEEE1588, benefit from the predictable delay of MPL-TP services.
2115
2116 The first phase of MPLS-TP specifications includes requirements (e.g. RFC5654[3]) and
2117 frameworks (e.g. RFC5921[4]) documents; architectural elements; a comprehensive set of
2118 transport-based operations, administration, and management tools for fault management and
2119 performance measurement; and a mechanism for transport-like linear protection.

2120 4.5.4 OTN

2121 The Optical Transport Network (G.709) technology offers a multi-service capable infrastructure
2122 supporting lambda and sub-lambda services with guaranteed quality. OTN is characterized by a

58
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2123 feature set and granularity that suits metro and core transport requirements, while mixing photonic
2124 and electronic technology in a complimentary way to achieve carrier grade OAM and resilience.
2125
2126 Some key features include:
2127  Future proof flexibility and scalability for any service mix and traffic distribution, enabling
2128 flexible grooming at lambda, port, and sub-port levels.
2129  Connection-oriented transport of any variable bit-rate, leveraging its flexible-sized container
2130 (1.25 Gbps increments), to enable full utilization of network resources
2131  Optimized support for Gigabit Ethernet services, ranging from 1 Gb/s to 100 Gb/s,
2132  Gigabit/ Multi-Gigabit -level bandwidth granularity required to scale and manage Multi-
2133 Terabit networks.
2134  Enhanced SLA verification capabilities in support of multi-carrier, multi-service environment.
2135
2136 Initial OTN technology built upon the industry’s positive experience with SDH/SONET, providing
2137 support for new revenue generating services, and solutions for offering enhanced OAM capabilities,
2138 while addressing inherent optical transmission challenges that did not exist for SDH (e.g., DWDM
2139 system engineering rules with/without flexible Optical NEs). Current OTN technology like OTUflex
2140 extends and enriches the foundation OTN hierarchy as a seamless transition towards enabling
2141 optimized service transparent support for an increasingly abundant service mix.
2142
SONET/SDH
SONET/SDH
OC-n/STM-n
OC-n/STM-n
Data
DataCenter,
Center,Video,
Video,SAN,
SAN,etc.
etc.
Infiniband,
Infiniband,FC,
FC,SBCON/ESCON,
SBCON/ESCON,SDI
SDI
Ethernet
Ethernet
1/10/40/100GE IP-MPLS/
IP-MPLS/
1/10/40/100GE
Eth
EthVLAN
VLAN
MPLS-TP
MPLS-TP

OTN “Digital
Wrapper”

ODU-k
ODU(flex)
1.25-100 Gb

OTN
Multiplexing

2143
2144 Figure 14: OTN multiplexing
2145 Integration of GMPLS optical control plane technology has enabled dynamically configurable OTN
2146 networking, with control plane survivability schemes expanding the data-plane protection solutions
2147 toolkit for network reliability and availability.
2148
2149 As a scalable, survivable, and manageable L1/L0 transport infrastructure, OTN complements
2150 higher Layer Packet Transport technologies in offering a robust foundation for Smart Grid
2151 applications.

59
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2152 4.5.5 Data services over SDH

2153 SDH was first introduced into the world’s telecommunications networks in the early 1990s, yet
2154 within five years of its launch had all but displaced the deployment of its predecessor, the
2155 Plesiochronous Digital Hierarchy (PDH) [3].
2156
2157 That this transition took place so quickly is not so difficult to explain [4]. User interfaces on SDH
2158 equipment remained those of the standard PDH rates of 2Mbit/s (E1), 34Mbit/s (E3) and 140Mbit/s
2159 (E4), whilst SDH technology delivered a decided improvement in the efficient dropping and
2160 inserting of any individual payload directly from the aggregate optical stream, without the need for
2161 PDH’s more convoluted de-multiplexing and re-multiplexing processes. Coupled with its
2162 comprehensive performance, fault management and sub-50ms autonomous payload protection,
2163 SDH offered operators greater networking flexibility, faster provisioning and substantial total cost of
2164 ownership benefits.
2165
2166 SDH’s benefits of adding and dropping traffic, together with its fast protection schemes, was best
2167 realized within fibre ring topologies, with their inherent spatial diversity and reduced fibre demands,
2168 compared to PDH’s previously established hub and mesh topologies. This had an immediate and
2169 lasting impact on network build, as fibre rings became the preferred topology, particularly in the
2170 access and metro environment.
2171
2172 Given all of SDH’s benefits, its almost universal deployment throughout all of today’s public
2173 telecommunications networks and its established operational practices, the key question now is
2174 whether and over what period SDH might, itself, succumb to the pressures from Ethernet, as the
2175 next generation transport technology.

2176 4.5.6 Mapping into SDH payloads

2177 The starting point was SDH (or its North America SONET counterpart). Its adoption was not only a
2178 major factor in shaping global network technology and operating practice, it was, also, instrumental
2179 in the literal shaping of the [ring based] fibre topologies.
2180
2181 Unsurprisingly, the first phase in handling Ethernet was built on SDH’s incumbency and proven
2182 performance. The addition of a simple process to map Ethernet into the SDH frame became the
2183 basis of what has become known as “Next Generation SDH (NG SDH)”.
2184
2185 Frequently, this capability was developed as an add-in card or “blade”, which could replace
2186 existing traffic cards in both existing and installed SDH equipment. This process of TDM to packet
2187 migration allowed the installed base to be progressively “upgraded” to support the introduction of
2188 Ethernet, in line with demand and without the need to replace existing equipment.
2189
2190 Very quickly, virtually all SDH equipment became NG SDH, consigning any product that did not
2191 come up to this level with the pejorative label, “legacy”. More specifically, to qualify as NG SDH,
2192 the minimum requirement was that traffic presented on a given Ethernet port could be mapped,
2193 using the ITU-T Generic Framing Procedure (GFP), into one or more SDH Virtual Containers
2194 (VCs).
2195
2196 To counter the large step in VC payload sizes (a VC-12 has an approximate 2Mbit/s payload
2197 capacity; VC-3 = 45Mbit/s; VC-4=150Mbit/s), an extension of the mapping procedure enabled the
2198 otherwise coarse steps of the individual VC payload granularities to be replaced by the
2199 construction of more elastic payloads from multiple smaller individual VCs to form a single, larger
2200 virtual concatenated payload (VCAT). In this way, for example, a 10Mbit/s Ethernet could be
2201 carried more efficiently in five VC-12s (5x 2Mbit/s) than if it had to be mapped into its nearest
2202 equivalent VC-3 (34Mbit/s) payload.
2203

60
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2204 The efficiency enabled by VCAT and GFP could be further extended to handle any fractional rate
2205 Ethernet service, down to granularities as small as 64kbit/s, depending on the implementation
2206 adopted by the NG SDH equipment vendor.
2207
2208 This ability to size the SDH payload to match the Ethernet rate led to two further opportunities to
2209 enhance NG SDH.
2210
2211 The first was the introduction of the ITU-T’s Link Capacity Adjustment Scheme (LCAS), which
2212 allowed the size of the VCAT to be seamlessly and automatically increased or decreased in
2213 service, in line with changes in payload requirements or under fault conditions.
2214
2215 The second was that the policing and shaping required for handling fractional Ethernet, laid the
2216 foundations for introducing Layer 2 bridging, aggregation, switching, grooming and for the handling
2217 of multiple flows per port, QoS levels etc.
2218
2219 Throughout, the initial deployment was characterized by a continuous process of adding packet
2220 functionality to an established SDH product architecture, with the advantages that existing SDH
2221 functionality was not compromised and the cost of migration was incurred only incrementally.
2222
2223 It, offered a quick and relatively painless first step on the road to deliver wide area packet
2224 networking for best effort, statistical gain services and for business services, such as E-LINE and
2225 VLAN services, on the shoulders of SDH’s proven carrier class performance.

2226 4.6 Higher level communication protocols

2227
2228 Smart grid applications and standards rely heavily on Web Services for the upper layers protocols.
2229 Web Services are defined to be the methods to communicate between applications over
2230 communication networks, generally IP based. Two major classes of Web Services can be
2231 distinguished (the pros/cons of each class are beyond the scope of this document). These are
2232 RESTful Web Services and SOAP/RPC based Web Services. More information on these two
2233 classes of Web Services is provided by the W3C under this link: http://www.w3.org/TR/ws-
2234 arch/#relwwwrest
2235
2236 The Web Services messaging protocols are designed to be independent of the underlying
2237 transport protocols. HTTP, XMPP and CoAP are the most relevant messaging /transport protocols.
2238
2239 The IEC TC57 WG17 is currently working on Web Services profiles for 61850 specifications.

2240 4.6.1 RESTful Web Services

2241
2242 REST (Representational State Transfer) is an architectural style defined by Roy T. Fielding in
2243 2000.
2244
2245 It is a set of principles that enable distributed systems to achieve greater scalability and allow
2246 distributed applications to grow and change over time, thanks to loose-coupling of components and
2247 stateless interaction.
2248
2249 The main concept of REST is that a distributed application is composed of RESOURCES, which
2250 are stateful pieces of information residing onto one or more servers.
2251
2252 Regardless of their content, in REST it is possible to manipulate them through a uniform interface
2253 that is composed of 4 basic interactions: CREATE, UPDATE, DELETE and READ.
2254

61
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2255 Each of these operations is composed of a request and a response messages, and, with the
2256 exception of CREATE, they are IDEMPOTENT, meaning that the end result of each operation
2257 does not change regardless how many times the operation itself is repeated. In other words, these
2258 operations do not have side-effects. This makes it distribute resources around and to proxy them,
2259 since the lack of side effects allows more efficient caching and scalability.
2260
2261 Most importantly however, since the same set of operations can manipulate the most diverse kind
2262 of resources, it is not necessary to develop a dedicated client or infrastructure whenever the
2263 application domain changes. Rather, the same underlying architecture can be reused times and
2264 times again in face of changes in the application space.
2265
2266 The most common implementation of REST is HTTP, where the above operations are mapped into
2267 the methods of this protocol: CREATE is mapped on HTTP POST, READ on HTTP GET, UPDATE
2268 on HTTP PUT and DELETE on HTTP DELETE.
2269
2270 However other implementations are possible: CoAP (Constrained Application Protocol), XMPP
2271 (Extensible Messaging and Presence Protocol), etc.

2272 4.6.2 SOAP/RPC Web Services

2273 SOAP/RPC based Web Services: applications expose interfaces that are described in machine
2274 processable format, the Web Service Description Language (WSDL). It is also possible for
2275 applications to interact through SOAP interfaces which provide a means to describe message
2276 format. These messages are often transported over HTTP and encoded using XML.
2277
2278 SOAP is method for exchanging XML based message over the Internet for providing and
2279 consuming web services. SOAP message are transferred forming the SOAP-Envelope.
2280
2281 RPC (remote procedure call) is another way of providing and consuming web services. It uses
2282 XML to encode and decode the remote procedure call along with its parameter.

2283 4.6.3 Architectures, Protocols and languages for Web Services

2284 4.6.3.1 HTTP

2285 According to Wikipedia, “The Hypertext Transfer Protocol (HTTP) is an application protocol for
2286 distributed, collaborative, hypermedia information systems. HTTP is the foundation of data
2287 communication for the World Wide Web”.
2288
2289 Hypertext is a multi-linear set of objects, building a network by using logical links (the so-called
2290 hyperlinks) between the nodes (e.g. text or words). HTTP is the protocol to exchange or transfer
2291 hypertext.
2292
2293 The standards development of HTTP was coordinated by the Internet Engineering Task Force
2294 (IETF) and the World Wide Web Consortium (W3C), culminating in the publication of a series of
2295 Requests for Comments (RFCs), most notably RFC 2616 (June 1999), which defines HTTP/1.1,
2296 the version of HTTP in common use.”
2297
2298 HTTPS is the secure version of HTTP based on Transport Layer Security (TLS).

2299 4.6.3.2 CoAP

2300 CoAP is an IETF defined protocol that aims at porting the features of a REST-based architecture
2301 to a wireless sensor network (although it can be used in other environments), in particular
2302 constrained networks supporting 6-LoWPAN.

62
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2303
2304 CoAP is a non-HTTP approach to REST. The reason for specifying CoAP is mainly motivated by
2305 the difficulty to implement HTTP in small, constrained devices or networks. Therefore, CoAP
2306 defines some primitives that allow REST on top of UDP.
2307
2308 In order to simplify the message format, the HTTP headers have been simplified to fixed-position,
2309 fixed-size binary fields inside a CoAP payload, and only a limited set of MIME types are available.

2310 4.6.3.3 XMPP

2311 XMPP is a communications protocol that permits bi-directional exchange of messages between
2312 entities using globally addressable clients and servers. In order to exchange messages between
2313 entities, the entities connect to a server as a client. The clients may connect to the same or
2314 different servers. In the case clients connecting to multiple servers, the servers to which the
2315 client(s) connect are themselves connected.
2316
2317 In order to exchange messages between XMPP clients, the client establishes an XML stream with
2318 a server by:
2319 Setting up a TCP session
2320 Negotiating a TLS encrypted XMPP channel
2321 Authenticating the XMPP channel using SASL credentials
2322 Binds the resource of full JID of the client
2323
2324 Once the client establishes the XML stream, the client then exchanges messages with other clients
2325 using XML Stanzas.

2326 4.6.3.4 ETSI M2M

2327 ETSI M2M architecture defines a set of standards that allow M2M communications using a REST
2328 architecture style. In ETSI M2M, applications publish resources which can be addressed using
2329 URLs. Every resource can be read, created, deleted or updated subject to access rights and
2330 related permissions which provide an adequate means to ensure privacy and security.
2331 The high level architecture framework for ETSI M2M is provided in the following figure:

63
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

M2M Applications

mIa

M2M
Management
M2M Service Capabilities Functions

Network Domain Core Network (CN)

Network
Management
Functions

Access Network

mId
M2M
Applications
M2MService
Capabilities
M2M Gateway

Device and Gateway M2MArea

M2M Area
Domain Network
Network M2M
Applications
M2M Service
M2M Capabilities
Device M2M Device
2332
2333 Figure 15: ETSI M2M architecture framework
2334
2335 In this architecture figure resources can be stored in the device M2M Service Capabilities, in the
2336 M2M gateway Service Capabilities or the in the M2M Service Capabilities in the Network domain.
2337 mId, mIa and dIa denote reference points which are specified according to the REST architecture
2338 style where both HTTP and CoAP can be supported (the dIa reference point, not shown in the
2339 figure, allows a device application to communicate to the M2M service capabilities in the Device).
2340 Mapping to other protocols is possible (e.g. XMPP) but the current ETSI specifications provide a
2341 mapping to HTTP and CoAP only. M2M service capabilities can be seen as a set of functions
2342 (such as data sharing, security and device management) which are exposed to applications via the
2343 RESTful reference points.

2344 4.6.3.5 XML

2345 According to Wikipedia: “Extensible Markup Language (XML) is a markup language that defines a
2346 set of rules for encoding documents in a format that is both human-readable and machine-
2347 readable. It is defined in the XML 1.0 Specification produced by the W3C, and several other
2348 related specifications,[5] all gratis open standards.
2349
2350 The design goals of XML emphasize simplicity, generality, and usability over the Internet. It is a
2351 textual data format with strong support via Unicode for the languages of the world. Although the
2352 design of XML focuses on documents, it is widely used for the representation of arbitrary data
2353 structures, for example in web services.”

2354 4.6.4 Performance considerations

2355 To keep the cost of network at reasonable level and at the same time assuring the right
2356 performance under any traffic condition specific rules for sizing and optimize the network design

64
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2357 have to be clearly defined. Network dimensioning aspects pertaining to the use of Web Services
2358 performance aspects will be handled in future versions of this document.
2359

65
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2360 5 Generic Use Cases and related Communication Architecture

2361 examples
2362 The intention of this section is to reference the generic use cases coming from the sustainable
2363 process group and to add the communication requirements, which will lead to proposed
2364 communication architecture.
2365
2366 In this version of the document only 3 use cases have been developed, more will be added in
2367 subsequent version.
2368
2369 Note: While the communication within the home network is out of scope for M490, the below use
2370 case provide information flows inside the residential environment for the sake of
2371 completeness and to aid the understanding of the use cases.

2372 5.1 Use cases

2373 5.1.1 Demand Response

2374 5.1.1.1 High level overview

2375 Demand response is the key reliability resource to the power system. It helps reduce the electricity
2376 consumption or smooth the load in peak demand in response to emergency, peak-load, and high-
2377 price conditions. Utilities and policymakers at all levels of government have long recognized the
2378 benefits of demand response. Demand response refers to all functions and processes applied to
2379 influence the behavior of energy consumption. In order to facilitate DR, feedback and visualization
2380 of energy consumption are necessary and as such, fast real-time (moderate latency 30-100 ms) &
2381 high availability network communication will be the critical component enabler. The communication
2382 aspect can range from simple signaling, e-mail, SMS, or a phone call to a person who manually
2383 switches a load on or off, to fully integrated load management, where many consumption devices
2384 are dynamically controlled according to profiles based on the availability or price of energy (tariffs).

2385 5.1.1.2 Communications requirements

2386 The table below lists the network communication requirements. Within the smart home which is not
2387 controlled by the utility providers, the requirements may vary.
2388

66
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2389 Table 10: Demand Response communication requirements

Data useCategory
Parameter Control/Protection Data Monitoring/Manage
s menttData

Latency In the range of seconds 5 – 10 Minutes

Data occurrence Minutes Minutes/Hours
interval
Method of Multicast/Broadcast Unicast/multicast
Communication /Unicast
Reliabilit High Medium
yData security High High
Data volume Bytes/Kilobytes Kilobytes/Megabytes
Priorit High Medium
yLevel assurance High Low
2390
2391 In addition to the above traditional communication requirement, ‘Smart Grid demand side’ network
2392 would have some non-traditional communication requirements. For example,
2393 • Longer Life Time Support - once deployed, the appliance may be used for more than ten
2394 years. This is as opposed to consumer electronics products that are normally replaced
2395 within 3-5 years
2396 • Plug and Play network- some may want to connect their appliances after purchase which
2397 may be 5 years later. Some may want to purchase appliances one by one, not at once.
2398 • Maximum Commonality- different markets/regions (e.g., EU/US/CN) and regulatory
2399 domains may require different set of data communication features among networked
2400 appliances, however, maximum data communication commonality may achieve broad
2401 market potential.
2402 • Lightweight- low processing ability is assumed in many existing home appliances.

2403 5.1.1.3 Controlling energy consumption or generation via CEMS

2404 The home is one of the very important components in the overall Smart Grid System. The home is
2405 full with appliances that consume, generate or store energy and the vast majority of appliances
2406 have no connectivity other than to the power socket. As today’s home becomes smarter (aka the
2407 Smart Grid demand side) the majority of the demand side devices is not yet networked and
2408 connected to the Smart Grid. In order to fill the gap between today’s and tomorrow’s ‘Smart Grid
2409 demand side’, data communication technologies & Customer Energy Management systems
2410 (CEMS/DRMS) will play a key role.

2411 Demand Response event signals are not sent to appliances directly, but to the customer’s Energy
2412 Management System (CEMS/DRMS) to trigger a user manually or a program that automatically
2413 manages load by interacting with a number of object devices associated with the CEMS/DRMS.

2414 This is based on a Flow of Communication from the Energy Service Provider to the Customer
2415 Energy Management system (CEMS/DRMS).

67
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2416 5.1.1.4 Proposed communication architecture setup – CEMS/DRMS

Demand Mechanisms and incentives for utilities, business, industrial, and residential customers to
Response (DR) cut energy use & smooth demand at peak times.
2417
2418 High Level functions
2419
0 A Price change schedule or signal is received from the Energy Service Provider to the CEMS &
Displayed on the IHD
1 Customer Reduces Their Usage in Response to variable or real-time Pricing or Voluntary Load
Reduction Events
2 Customer Uses an EMS or IHD for real-time feedback on their usage, costs and projected bill.
3 Customer Uses Smart Appliances
4 CEMS/DRMS Manages Demand Through Direct Load Control (Out of Scope)
5 CEMS/DRMS Manages Demand in Response to Pricing Signal
6 External clients use the AMI to interact with devices at customer site (e.g. measurement and
verification)
7 Dynamic pricing - ESP Energy and Ancillary Services Aggregation
8 Utility Procedures Energy and Settles Wholesale Transactions Using Data from AMI System
9 Voltage, Var, and Watt Control (VVWC) with DR, DER, PEV, and ES
10 Energy control
11 Energy management service
12 Dynamic pricing related service
13 Dynamic pricing information transfer to BEMS through ESI
14 DR message transfer to BEMS through ESI
15 Demand response signal generation for controlling home appliances (Out of Scope)
16 Verification of a price change signal.
2420
2421 Communication Requirements
2422
2423 • End to end delay shall aim to be less than: 5s.
2424 • Support for communication includes short and long range.
2425 • Resiliency: the impact of failure in the telecommunications networks should not be noticed
2426 by applications.
2427 • Standard Data Model that can work seamlessly over any communication media
2428 • Time synchronization
2429 • Secure Communication
2430 • Confidentiality data Integrity
2431 • Mutual Authentication
2432 • Notify transactions for informational & metering services
2433 • Acknowledged transactions for time critical services
2434 • Different regulations will exist for the Interface from ESP to CEMS. DRMS, hence a variety
2435 of communication Standards & paths are required.
2436
2437 Proposed Communication Architecture Setup
2438
2439 The figure below depicts an example communication architecture whereby ‘Smart Grid demand
2440 side’ devices are connected via network adapter and each adapter represents a communication
2441 interface point through which the network controller is connected. The utility network is connected
2442 either via AMI networks or neighborhood area network (NAN) or directly using broadband network
2443 such as cellular data network.
2444
2445 Note: Dashed circles indicate the likely home networks. Red dashed ellipse is the Utility Smart
2446 Meter network. The Green dashed ellipse is the ISP Home entertainment/appliance

68
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2447 network. These networks may overlap at the IP layer with communications Gateways to the
2448 NAN/LAN. The IP Router & PC are illustrative and do not imply the location of routing,
2449 gateway & controller functionality, as the entire Home network may be a tree, bus or mesh
2450 it is not clear where the controller functions reside. IP routers may exist in every node &
2451 appliance, IP Gateways are required by the Premises(CPN), NAN & LAN owners.
Wired / Wireless

Home
Network
IP
Route
r

WAN

SG
Gateway

SG Demand
SM/AMI Gateway Side

Wired / Smart Grid Demand Side

Wireless

2452
2453 Figure 16: Smart Home Communication Example architecture

2454 5.1.1.5 Flows for Demand response with CEMS

2455 5.1.1.5.1 Functional Architecture for Demand response

2456 This is a generic Demand Response Architecture taken to represent the Functional entities in
2457 scenario with communication via a CEMS and scenario with direct communication from Smart
2458 appliances (and an optional CEMS).

69
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2459
2460 Figure 17: Demand Response functional Architecture

2461 5.1.1.5.2 Use case scenario 1a: Information regarding power consumption or generation of
2462 individual appliances/generators

2463

70
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Information regarding power consumption / generation of individual appliances

Actor MDM H NN Smart Metering Actor Energy CEM Smart Display

B ES AP Gateway A Management S Appliances /
(LNAP) Gateway Generators

Individual appliance consumption / generation

information

Parallel Total and/or forecased house consumption / generation

Total and/or forecased house consumption / generation

Total and/or forecased house consumption / generation

Total and/or forecased house consumption / generation

Total and/or forecased house consumption / generation

Total and/or forecased house consumption / generation

Total and/or forecased house consumption / generation

Total and/or forecased house consumption / generation

1
2464

2465 Step by Step Analysis of Use Case

2466
S.No Primary Actor Triggering Event Pre-Condition Post-Condition
Smart appliance / New consumption / Communication connection (forecasted) consumption /
Generator generation information is between all actors is generation is received by
available in the smart established actor A and/or actor B
appliance / generator and/or display
2467
Scenario Name :
Step Event Description of Information Information Information Zones / Domains Ref.
No. Process/Activity Producer Receiver Exchanged
1 New consumption / Smart appliance / Smart CEMS Individual Field / Customer FINS-
generation generator sends appliance / appliance premise 0089 p
information is information generator consumption 2
available in the regarding / generation
smart consumption to
appliance/generator the CEMS

71
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Scenario Name :
Step Event Description of Information Information Information Zones / Domains Ref.
No. Process/Activity Producer Receiver Exchanged
2 CEMS received The CEMS CEMS Display Total and/or Field / Customer FINS-
consumption / aggregates and/or forecasted premise 0090 p
generation forecasts total house 2
information per consumption and consumption FINS-
individual appliance sends this / generation 0089 p
information to the 2
display
3a CEMS received The CEMS CEMS Energy Total and/or Field / Customer
consumption / aggregates and/or Management forecasted premise
generation forecasts total Gateway house
information per consumption and consumption
individual appliance sends this / generation
information to the
Energy
Management
Gateway
(alternative)
3b Energy Management Energy Energy Actor A Total and/or Field - Enterprise /
Gateway received Management Management forecasted Customer premise
(forecasted) Gateway forwards Gateway house
consumption / information to consumption
generation Actor A / generation
4a CEMS received The CEMS CEMS Smart Total and/or Field / Customer
consumption / aggregates and/or Metering forecasted premise
generation forecasts total Gateway house
information per consumption and (LNAP) consumption
individual appliance sends this / generation
information to
Smart Metering
Gateway (LNAP)
(alternative)
4b Smart Metering Smart Metering Smart HES Total and/or Field-station-
Gateway (LNAP) Gateway (LNAP) Metering forecasted operation/Customer
receives forwards Gateway house premise
(forecasted) information to (LNAP) consumption
consumption / HES (optional: / generation
generation signal is sent
through NNAP)
4c HES receives HES forwards HES MDM Total and/or Operation – ESMIG-
(forecasted) information to forecasted Enterprise 0001
consumption / MDM house /Customer premise 7.2.1
generation consumption
/ generation
4d MDM receives MDM forwards MDM Actor B Total and/or Enterprise/customer ESMIG-
(forecasted) information to forecasted premise 0001
consumption / Actor B house 7.2.1
generation consumption
/ generation
2468

2469 5.1.1.5.3 Use case scenario 1b: Information regarding total power consumption or
2470 generation

2471

72
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2472 Drawing or Diagram of Use Case

Information regarding total power consumption

Actor MD H NN Smart Metering Actor Energy Smart CEM Smart Displ

B M ES AP Gateway A Managemen Meter S Appliances / ay
(LNAP) t Gateway Functionalit Generators
y

Total house consumption

Total house
consumption

Parallel Total and/or forecased house consumption

Total and/or forecased house consumption

Forecased house consumption

Total and/or forecased house consumption

Total and/or forecased house consumption

Total and/or forecased house consumption

Total and/or forecased house consumption

Total and/or forecased house consumption

2473
2474 Step by Step Analysis of Use Case

S.No Primary Actor Triggering Event Pre-Condition Post-Condition

Smart Meter New Communication connection (forecasted)
consumption/generation between all actors is consumption/generation
information is available in established information is received by
the Smart Meter actor A and/or or Actor B
and/or display
2475
Scenario Name :
Step Event Description of Information Information Information Zones / Domains Ref.
No. Process/Activity Producer Receiver Exchanged
1 New The Smart Meter Smart Meter Smart Consumption Field / Customer
consumption/ forwards the Metering information premise
generation consumption Gateway
information is information to the (LNAP)
available in the Smart Metering
Smart Meter Gateway (LNAP)
2 Smart Smart Metering Smart CEMS Consumption Field / Customer
Metering Gateway (LNAP) Metering information premise
Gateway forwards the Gateway
(LNAP) consumption (LNAP)
receives the information to CEMS
information

73
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Scenario Name :
Step Event Description of Information Information Information Zones / Domains Ref.
No. Process/Activity Producer Receiver Exchanged
3 New The CEMS may CEMS Display Total and/or Field / Customer FINS-
consumption forecast total forecasted premise 0089 p 2
information is consumption and house FINS-
available in the sends (forecasted) consumption 0090 p 2
CEMS consumption
information to the
display
4a CEMS The CEMS CEMS Energy Total and/or Field / Customer DKE0014
received aggregates and/or Management forecasted premise
consumption forecasts total Gateway house
information per consumption and consumption
individual sends this
appliance information to the
Energy
Management
Gateway
(alternative)
4b Energy Energy Energy Actor A Total and/or Field - enterprise/ DKE0014
Management Management Management forecasted Customer premise
Gateway Gateway forwards Gateway house
received information to Actor consumption
(forecasted) A
consumption
5a CEMS The CEMS CEMS Smart Total and/or Field / Customer DKE0014
received aggregates and/or Metering forecasted premise
consumption forecasts total Gateway house
information per consumption and (LNAP) consumption
individual sends this
appliance information to Smart
Metering Gateway
(LNAP) (alternative)
5b Smart Smart Metering Smart HES Total and/or Field-station-
Metering Gateway (LNAP) Metering forecasted operation/Customer
Gateway forwards information Gateway house premise
(LNAP) to HES (LNAP) consumption
receives (optional: signal is
(forecasted) sent through NNAP)
consumption
5c HES receives HES forwards HES MDM Total and/or Operation - ESMIG-
(forecasted) information to MDM forecasted Enterprise/customer 0001
consumption house premise 7.2.1
consumption
5d MDM receives MDM forwards MDM Actor B Total and/or Enterprise/customer ESMIG-
(forecasted) information to Actor forecasted premise 0001
consumption B house 7.2.1
consumption
2476

2477 5.1.1.5.4 Use case scenario 2: Price and environmental information

2478 Drawing or Diagram of Use Case

74
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Price & environmental information

Actor MD H NN Smart Metering Actor Energy CEM Smart Displ

B M ES AP Gateway A Manageme S Applianc ay
(LNAP) nt Gateway es

Price and environmental information

Price and environmental information

Parallel
Price and environmental information Confirmation

Price and environmental

information
Price and environmental information

Price and environmental information

Price and environmental information

Parallel
Confirmation

Confirmation

Confirmation

New price and environmental information

New price and environmental information

Confirmation reception new price and environmental

information

2479

2480 Step by Step Analysis of Use Case

2481
S.No Primary Actor Triggering Event Pre-Condition Post-Condition
Actor A or actor B New price and Communication connection Price and environmental
environmental information between all actors is information is received by
is available in Actor A or established Smart Appliances
Actor B
2482
Scenario Name :
Step Event Description of Information Information Information Zones / Ref.
No. Process/Activity Producer Receiver Exchanged Domains
1a New price and/or Actor A sends information to Actor A Energy Price and/or Enterprise – DKE00
environmental is Energy Management Managemen environmental field 14p 7
available in actor A Gateway t Gateway information /customer
(alternative) premise
1b Energy Energy Management Energy CEMS Price and/or Field/ DKE00
Management Gateway forwards price Managemen environmental customer 14p 7
Gateway received and/or environmental t Gateway information premise
information informatio n to CEMS
1c Energy Energy Management Energy Actor A Confirmation Field – DKE00
Management Gateway sends confirmation Managemen Enterprise / 14p 7
Gateway received to Actor A (alternative) t Gateway Customer
information premise
2a New price and/or Actor B esends price and/or Actor B MDM Price and/or Enterprise / ESMIG
environmental is environmental information to environmental Customer 0006

75
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Scenario Name :
Step Event Description of Information Information Information Zones / Ref.
No. Process/Activity Producer Receiver Exchanged Domains
available in actor B MDM information premise
2b MDM receives MDM determines all MDM HES Price and/or Enterprise- ESMIG
price and/or consumers involved environmental Operation / 0006
environmental by the price information Customer
information and/or environmental premise
information and
routes the information to the
HES
2c HES receives HES forwards price and/or HES Smart Price and/or Operation –
information by environmental information to Metering environmental station –
MDM Smart Metering Gateway Gateway information field /
(LNAP) (LNAP) customer
(optional: signal is sent premise
through NNAP)

2d Smart Metering Smart Metering Gateway Smart CEMS Price and/or Field / TC205
Gateway (LNAP) (LNAP) forwards price Metering environmental Customer p4-40
receives and/or environmental Gateway information premise
information information to CEMS (LNAP) DKE00
14p 7
3a Smart metering Smart metering gateway Smart HES Confirmation Field –
Gateway (LNAP) sends confirmation to HES Metering Operation /
received (alternative) Gateway Customer
information (optional: signal is sent premise
through NNAP)
3b HES received HES forwards confirmation HES MDM Confirmation Operation – ESMIG
confirmation to MDM Enterprise / 0006
Customer
premise
4 CEMS received CEMS identifies relevant CEMS Smart Price and/or Field / DKE00
new price and/or Smart Appliances and Appliciances environmental Customer 14p 7
environmental forwards the new price information premise
information and/or environmental
information to the Smart
Appliances
5 CEMS received CEMS forwards the new CEMS Display Price and/or Field /
new price and/or price and/or environmental environmental Customer
environmental information to the Display information premise
information
6 Smart Appliances Smart Appliances confirm Smart CEMS Confirmation Field / DKE00
receive new price reception to CEMS Appliances Customer 14p 7
and/or premise
environmental
information

2483 5.1.1.5.5 Use case scenario 3a: Warning signals based individual appliances consumption

2484 Drawing or Diagram of Use Case

76
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

CEMS Smart Displa

Appliances y
Information on total
consumption &
subscribed power
Warning signal

Warning signal
2485
2486
2487 Step by Step analysis of Use Case

S.No Primary Actor Triggering Event Pre-Condition Post-Condition

Smart appliance The CEMS received The subscribed power Warning signal is
information on a new limits are made known to received by display
operation to be executed the smart appliance and/or smart appliances
2488
Scenario Name :
Step Event Description of Information Information Information Zones / Ref.
No. Process/Activity Producer Receiver Exchanged Domains
1 The CEMS The CEMS sends CEMS Smart Total house Field / FINS0088
received information on total house appliance consumption Customer p2
information on a consumption and subscribed and premise
new operation to power to the appliance subscribed FINS0048
be executed involved power p27
2 The smart The smart appliance Smart CEMS Warning Field / FINS0088
appliance estimates the maximum Appliance message Customer p2
received power tobe consumed for the premise
information on operation and deducts this FINS0048
total house from the available power. In p27
consumption and case there is insufficient
subscribed power power available, it displays a
to the appliance warning message and sends
a warning message to the
CEMS
3 The CEMS The CEMS sends the CEMS Simple Warning Field / FINS0088
received a warning message to the external message Customer p2
warning message external display consumer premise
display FINS0048
p27
2489

2490 5.1.1.6 Proposed communication architecture setup – Smart Home with direct
2491 communication with Smart Appliances

2492 The home is one of the very important components in the overall Smart Grid System. The home is
2493 full with appliances that consume, generate or store energy the vast majority of appliances will
2494 have direct connectivity with the Internet & Smart Grid, as well as connectivity via the power. As
2495 today’s home becomes smarter (a.k.a. the Smart Grid demand side) the majority of the demand
2496 side appliances will be networked and connected to the Internet & Smart Grid. Within tomorrow’s
2497 ‘Smart Grid demand side’, data communication technologies will play a key role.

77
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2498 Demand Response event signals are sent to smart appliances directly and to the customer’s
2499 Energy Management System (CEMS/DRMS). The pre-configured program that automatically
2500 manages load by interacting with a number of object devices associated with the CEMS/DRMS
2501 becomes less important.

2502 This is based on a Flow of Communication from the Energy Service Provider to the Smart
2503 Appliances.
2504
Demand Mechanisms and incentives for utilities, business, industrial, and residential customers to
Response (DR) cut energy use & smooth demand at peak times.
2505
2506 High Level functions
2507
0 A Price change schedule or signal is received from the Energy Service Provider to the CEMS &
Smart appliances
2 Customer Uses an EMS or IHD for real-time feedback on their usage, costs and projected bill.
3 Customer may use Smart Appliances
4 CEMS/DRMS Manages Demand Through Direct Load Control (Out of Scope)
6 External clients use the AMI to interact with devices at customer site (e.g. measurement and
verification)
7 Dynamic pricing - ESP Energy and Ancillary Services Aggregation
8 Utility Procedures Energy and Settles Wholesale Transactions Using Data from AMI System
9 Voltage, Var, and Watt Control (VVWC) with DR, DER, PEV, and ES
10 Energy control
11 Energy management service
12 Dynamic pricing related service
13 Dynamic pricing information transfer to BEMS through ESI
14 DR message transfer to BEMS through ESI
15 Demand response signal generation for controlling home appliances (Out of Scope)
16 Verification of Price change signal
2508
2509 Communications requirements
2510
2511 • End to end delay shall aim to be less than: 5s for control signals.
2512 • Support for communication includes short and long range.
2513 • Resiliency: the impact of failure in the telecommunications networks should not be noticed
2514 by applications.
2515 • Standard Data Model that can work seamlessly over any communication media
2516 • Time synchronization
2517 • Secure Communication
2518 • Confidentiality data Integrity
2519 • Mutual Authentication
2520 • Notify transactions for informational & metering services
2521 • Acknowledged transactions for time critical services
2522 • Non repudiated delivery for critical and billing type transactions.
2523 • Different regulations will exist for the Interface from ESP to Smart Home, hence a variety of
2524 communication Standards & paths are required.
2525
2526 Proposed communications architecture setup
2527
2528 The figure below depicts an example communication architecture whereby ‘Smart Grid demand
2529 side’ devices & appliances are directly connected & controlled to the Smart Grid and endpoint is a
2530 communication interface point where controller is connected. The utility network is connected

78
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2531 either via AMI networks or neighborhood area network (NAN) or directly using broadband network
2532 such as cellular data network.
2533
2534 Note: Dashed circles indicate the likely home networks. Red dashed ellipse is the Utility Smart
2535 Meter network. The Green dashed ellipse is the ISP Home entertainment/appliance
2536 network. These networks may overlap at the IP layer with communcations Gateways to the
2537 NAN/LAN. The IP Router & PC are illustrative and do not imply the location of routing,
2538 gateway & controller functionality, as the entire Home network may be a tree, bus or mesh
2539 it is not clear where the controller functions reside. IP routers may exist in every node &
2540 appliance; IP Gateways are required by the Premises (CPN), NAN & LAN owners.
2541

2542
2543 Figure 18: Smart Home Communication Example architecture

2544 5.1.1.7 Flows for Demand response - with Direct control of Smart Appliances

2545 5.1.1.7.1 Functional Architecture for Demand response

2546 This is a generic Demand Response Architecture taken to represent the Functional entities in
2547 scenario with communication via a CEMS and scenario with direct communication from Smart
2548 appliances (and an optional CEMS).
2549

79
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2550
2551 Figure 18: Demand Response functional Architecture

2552 5.1.1.7.2 Use case scenario 1: Direct load management - appliance has end-decision about
2553 its load adjustment

2554 Note: in order to keep this use case clear, only “load management” and “changes in
2555 consumption” are described. Please note that this use case is also applicable on
2556 generation management or storage management.

2557 Drawing or Diagram of Use Case

80
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

DIRECT LOAD MANAGEMENT – appliance has end-decision about its load adjustment

MD H NN Smart C Actor Energy CEM Smart Disp

Actor
M E AP Metering C A Managemen S Applianc lay
B
S Gateway M t Gateway es /
(LNAP) Generato
Load management command
rs
Load management command

Announcement of load adjustment

Load management command

Parallel Start of load adjustment notification

Order of load adjustment

Feedback
status
Expected change in
consumption
Expected change in
consumption

End of load adjustment notification

Parallel
End of load adjustment

Feedback
status
End of load adjustment period + sending load curve recorded for this
period

End of load adjustment period + sending load curve recorded for this period

2558

2559 Step by Step Analysis of Use Case

2560
S.No Primary Actor Triggering Event Pre-Condition Post-Condition
Actor A or Actor B Actor A or Actor B wants to Communication The Smart Appliance /
connection between all
send a load management generator executed the load
actors is established
command to the market management command and
The consumer configured Actor A or Actor B received
the CEMS and/or the the feedback with a load curve
participating devices
recorded for this period
(appliances and
generators). The
consumer configured the
device settings and
thresholds

Information on total
consumption or
consumption per
appliance is available in
the CEMS

81
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2561
2562
Scenario Name :
Step Event Description of Information Information Information Zones / Ref.
No. Process/Activity Producer Receiver Exchanged domains
1a Actor A sends a load Actor A Energy Load Enterprise DKE0020
management command to Managemen management – field /
Energy Management t Gateway command Customer
Gateway premise
1b Energy Energy Management Energy CEMS Load Field/ DKE0020
Management Gateway forwards the load Managemen management Customer
Gateway receives management command to t Gateway command premise
a load CEMS
management
command from
Actor A
2a Actor B wants to Actor B sends a load Actor B MDM Load Enterprise ESMIG00
send a load management command to management / 17
management MDM command Customer
command to the premise
market (alternative)
2b MDM receives a MDM decides on which MDM CCM Announcement Enterprise FINS-
load management loads to adjust and sends an of load / 0048
command from announcement of the load adjustment Customer 3.5.4 p30,
Actor B adjustment notification to premise ESMIG00
CCM 14
2c MDM receives a MDM decides on which MDM HES Load Enterprise DKE-0020
load management loads to adjust and sends a management - ESMIG00
command from load management command command operation/ 17
Actor B to HES Customer
premise
2d HES receives the HES forwards the load HES Smart Load Operation FINS-
load management management command to Metering management - station - 0048
command from Smart Metering Gateway Gateway command field/ 3.5.4 p30
MDM (LNAP) (optional: signal is (LNAP) Customer
sent through NNAP) premise

2e Smart Metering Smart Metering Gateway Smart CEMS Load Field/

Gateway (LNAP) (LNAP) forwards the load Metering management Customer
receives the load management command to Gateway command premise
management CEMS (LNAP)
command from
HES
3 CEMS receives the CEMS sends the start of CEMS Display Load Field/ FINS-
load management load management management Customer 0048
command from notification to Display command premise 3.5.4 p30
Energy
Management
Gateway or Smart
Metering Gateway
(LNAP)

82
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Scenario Name :
Step Event Description of Information Information Information Zones / Ref.
No. Process/Activity Producer Receiver Exchanged domains
4 CEMS receives the CEMS decides which Smart CEMS Smart Order of load Field/ DKE-
load management Appliances needs to be Appliances / adjustment Customer 0021p8
command from adjusted and sends an order generators premise TC205 –
Energy of load adjustment to the 0001 to
Management Smart Appliances / 0043 p80
Gateway or Smart generators
Metering Gateway
(LNAP)
5 Smart Appliances / The Smart Appliances / Smart CEMS Load adjustment Field/ FINS-
generators receive generators decide to switch Appliances / feedback Customer 0048
the order of load on/off based on the generators premise 3.5.4 p30
adjustment consumer’s settings and DKE-
send feedback to CEMS 0021p8
TC205 –
0001 to
0043 p80
6a CEMS receives CEMS informs Energy CEMS Energy Change in Field/ DKE0020
feedback from Management Gateway on Managemen consumption Customer
smart appliances / which change in t Gateway premise
generators consumption to expect.
(alternative)
6b Energy Energy Management Energy Actor A Change in Field - DKE0020
Management Gateway forwards the Managemen consumption enterprise
Gateway receives change in consumption to t Gateway /
the change in Actor A Customer
consumption from premise
CEMS
7a CEMS receives CEMS informs Smart CEMS Smart Change in Field/ FINS-
feedback from Metering Gateway on which Metering consumption Customer 0048
smart appliances change in consumption to Gateway premise 3.5.4 p30
expect. (alternative)
7b Smart Metering Smart Metering Gateway Smart HES Change in Field –
Gateway receives forwards the change in Metering consumption station -
the change in consumption to HES Gateway operation/
consumption from (optional: signal is sent Customer
CEMS through NNAP) premise
7c HES receives the HES forwards the change in HES MDM Change in Operation ESMIG00
change in consumption to MDM consumption - 17
consumption from enterprise
Smart Metering /
Gateway Customer
premise
7d MDM receives the MDM forwards the change in MDM Actor B Change in Enterprise ESMIG00
change in consumption to Actor B consumption / 17
consumption from Customer
HES premise
8 Load adjustment CEMS sends an end of load CEMS Smart End of load Field/ FINS-
period is finished adjustment to Smart Appliances / adjustment Customer 0048
Appliances generators premise 3.5.4 p30
9 Smart Appliances / The Smart Appliances / Smart CEMS End of load Field/ FINS-
generators receive generators switch on/off and Appliances / adjustment Customer 0048
the end of load send feedback to CEMS generators feedback premise 3.5.4 p30
adjustment from
CEMS

83
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Scenario Name :
Step Event Description of Information Information Information Zones / Ref.
No. Process/Activity Producer Receiver Exchanged domains
10 CEMS receives the CEMS sends the end of load CEMS Display End of load Field/ FINS-
feedback from adjustment notification to adjustment Customer 0048
Smart Appliances / Display premise 3.5.4 p30
generators
11a CEMS receives the CEMS sends the end of load CEMS Energy Load adjustment Field/ FINS-
feedback from adjustment period to Energy Managemen feedback Customer 0048
Smart Appliances Management Gateway and t Gateway premise 3.5.4 p30
sends a load curve recorded
for this period (alternative)
11b Energy Energy Management Energy Actor A Load adjustment Field - FINS-
Management Gateway forwards the Managemen feedback enterprise 0048
Gateway receives feedback to Actor A t Gateway / 3.5.4 p30
the feedback from Customer
CEMS premise
12a CEMS receives the CEMS sends the end of load CEMS Smart Load adjustment Field/ FINS-
feedback from adjustment period to Smart Metering feedback Customer 0048
Smart Appliances Metering Gateway (LNAP) Gateway premise 3.5.4 p30
and sends a load curve (LNAP)
recorded for this period
(alternative)
12b Smart Metering Smart Metering Gateway Smart HES Load adjustment Field –
Gateway (LNAP) (LNAP) forwards the Metering feedback station -
receives the feedback to HES Gateway operation/
feedback from (optional: signal is sent (LNAP) Customer
CEMS through NNAP) premise
12c HES receives the HES forwards the feedback HES MDM Load adjustment Operation FINS-
feedback from to MDM feedback - 0048
Smart Metering enterprise 3.5.4 p30
Gateway (LNAP) / ESMIG00
Customer 17
premise
12d MDM receives the MDM forwards the feedback MDM Actor B Load adjustment Enterprise FINS-
feedback from HES to Actor B feedback / 0048
Customer 3.5.4 p30
premise ESMIG00
17
2563
2564 Alternative scenarios
2565 1. Customer derogates before the start of the load management period (FINS-0048 3.5.4 p30)
2566 2. Customer derogates during the load management period (FINS-0048 3.5.4 p30)
2567 a. CEMS sends an end of load management to Smart Appliances (FINS-0048 3.5.4 p30)
2568 b. Smart Appliances send feedback to CEMS

2569 5.1.1.7.3 Use case scenario 2: Direct load management – the appliance has no control over
2570 its own load adjustment

2571 Note: initially for this Use Case only “load management” and “changes in cons umption” are
2572 described. Please note that this use case is equally applicable on generation
2573 management or storage management.

2574 Drawing or Diagram of Use Case

84
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

DIRECT LOAD MANAGEMENT – appliance has end-decision about its load adjustment

MD H NN Smart C Actor Energy CEM Smart Disp

Actor
M E AP Metering C A Managemen S Applianc lay
B
S Gateway M t Gateway es /
(LNAP) Generato
rs
Load management command

Load management command

Announcement of load adjustment

Load management command

Parallel Start of load adjustment notification

Order of load adjustment

Feedback
status

Expected change in
consumption

Expected change in
consumption

End of load adjustment notification

Parallel
End of load adjustment

Feedback
status
End of load adjustment period + sending load curve recorded for this
period

End of load adjustment period + sending load curve recorded for this period

1
2575

2576 Step by Step Analysis of Use Case

2577
S.No Primary Actor Triggering Event Pre-Condition Post-Condition
Actor A or Actor B Actor A or Actor B wants to Communication between all actors The appliance executed
send a load management can be established the load management
command to the market command and Actor A or
The consumer configured the CEMS Actor B received the
and/or the participating devices feedback
(appliances and generators). The
consumer configured the device
settings and thresholds

Information on total consumption or

consumption per appliance is
available in the CEMS
2578
2579

85
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Scenario Name :
Step Event Description of Information Information Information Technical Ref.
No. Process/Activity Producer Receiver Exchanged Require-
ments ID
1a Actor A wants to Actor A sends a load Actor A Energy Load Enterprise - DKE0020
send a load management command to Managemen management field/
management Energy Management t Gateway command Customer
command to the Gateway premise
market (alternative)
1b Energy Energy Management Energy CEMS Load Field/ DKE0020
Management Gateway forwards the load Managemen management Customer
Gateway receives management command to t Gateway command premise
a load CEMS
management
command from
Actor A
2a Actor B wants to Actor B sends a load Actor B MDM Load Enterprise/ ESMIG00
send a load management command to management Customer 17
management MDM command premise
command to the
market (alternative)
2b MDM receives a MDM decides on which MDM HES Load Enterprise - FINS-
load management loads to adjust and sends a management operation/ 0048
command from load management command command Customer 3.5.4 p30,
Actor B to HES premise ESMIG00
14
2c HES receives the HES forwards the load HES Smart Load Operation –
load management management command to Metering management station -
command from Smart Metering Gateway Gateway command field/
MDM (LNAP) (optional: signal is (LNAP) Customer
sent through NNAP) premise

2d Smart Metering Smart Metering Gateway Smart CEMS Load Field/ FINS-
Gateway (LNAP) (LNAP) forwards the load Metering management Customer 0048
receives the load management command to Gateway command premise 3.5.4 p30
management CEMS (LNAP) TC205 –
command from 0001 to
HES 0043 p60
3 CEMS receives the CEMS sends the start of CEMS Display Load Field/ FINS-
load management load adjustment notification adjustment Customer 0048
command from to Display notification premise 3.5.4 p30
Energy
Management
Gateway or Smart
Metering Gateway
4 CEMS receives the CEMS decides which CEMS Smart Order of load Field/ DKE-
load management generator/smart appliance Appliance/G adjustment Customer 0021p8
command from needs to be adjusted and enerators premise TC205 –
Energy sends an order of load 0001 to
Management adjustment 0043 p60
Gateway or Smart
Metering Gateway

86
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Scenario Name :
Step Event Description of Information Information Information Technical Ref.
No. Process/Activity Producer Receiver Exchanged Require-
ments ID
5 Smart The Smart Smart CEMS Load Field/ FINS-
Appliance/generato Appliance/generator Appliance/G adjustment Customer 0048
r receives the order switches on/off and sends enerator feedback premise 3.5.4 p30
of load adjustment feedback to CEMS DKE-
0021p8
TC205 –
0001 to
0043 p60
6 Smart Appliance / CEMS sends an end of load CEMS Smart End of load Field/ FINS-
generator adjustment to Smart Appliance/G adjustment Customer 0048
adjustment period Appliance/generator enerator premise 3.5.4 p30
is finished
7 Smart The Smart Smart CEMS End of load Field/ FINS-
Appliance/Generat Appliance/Generator switchs Appliance/G adjustment Customer 0048
or receives the end on/off and sends feedback enerator feedback premise 3.5.4 p30
of load adjustment to CEMS
from CEMS
8 CEMS receives the CEMS sends the end of load CEMS Display End of load Field/ FINS-
feedback from adjustment notification to adjustment Customer 0048
Smart Display premise 3.5.4 p30
Appliance/Generat
or
9a CEMS receives the CEMS sends the end of load CEMS Energy Load Field/ FINS-
feedback from adjustment period and a Managemen adjustment Customer 0048
Smart load curve recorded for this t Gateway feedback premise 3.5.4 p30
Appliance/Generat period to the Energy
or Management Gateway
(alternative)
9b Energy Energy Management Energy Actor A Load Field - FINS-
Management Gateway forwards the end of Managemen adjustment enterprise/ 0048
Gateway receives load adjustment period with t Gateway feedback Customer 3.5.4 p30
the end of load feedback to Actor A premise
adjustment period
with feedback from
CEMS
10a CEMS receives the CEMS sends the end of load CEMS Smart Load Field/ FINS-
feedback from adjustment period and a Metering adjustment Customer 0048
Smart load curve recorded for this Gateway feedback premise 3.5.4 p30
Appliance/Generat period to the Smart Metering (LNAP)
or Gateway (LNAP)
(alternative)
10b Smart Metering Smart Metering Gateway Smart HES Load Field-
Gateway (LNAP) (LNAP) forwards the end of Metering adjustment station-
receives the end of load adjustment period with Gateway feedback operation/
load adjustment feedback to HES (LNAP) Customer
period with (optional: signal is sent premise
feedback from through NNAP)
CEMS
10c HES receives the HES forwards the end of HES MDM Load Operation - ESMIG00
end of load load adjustment period with adjustment enterprise/ 17
adjustment period feedback to MDM feedback Customer
with feedback from premise
Smart Metering
Gateway (LNAP)

87
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Scenario Name :
Step Event Description of Information Information Information Technical Ref.
No. Process/Activity Producer Receiver Exchanged Require-
ments ID
10d MDM receives the MDM forwards the end of MDM Actor B Load Enterprise/ ESMIG00
end of load load adjustment period with adjustment Customer 17
adjustment period feedback to Actor B feedback premise
with feedback from
HES
2580

2581 5.1.2 Distribution Automation FLISR

2582 5.1.2.1 FLISR: Fault Location Isolation and Service Recovery

2583 5.1.2.1.1 High level overview

2584 FLISR automates the management of faults in the distribution grid. It supports the localization of
2585 the fault, the isolation of the faulty equipment(s) from the healthy equipment and the restoration of
2586 the healthy equipment. FLISR is typically applied in the MV network. During disturbances the
2587 automatic fault handling shortens outage time and offloads the operators in the distribution control
2588 center for more complicated situations. Therefore FLISR may help to improve performance
2589 indexes like SAIDI (System Average Interruption Duration Index).
2590
2591 Utilities that operate networks have a need for fast fault awareness, faulty section identification,
2592 rapid information gathering and analysis of switching options to restore service when a part of the
2593 consumers, attached to the concerned feeder is lost. Without this capability, it makes 8 hours or
2594 more to restore power should an inner city substation be lost. This application runs at a control
2595 centre level, with tight connection with field devices acting either as sensors or actuators.
2596 Implementing FLISR helps Utility to improve the performance based rates (PBR) and reduce the
2597 risk of penalties. The rules for PBR will vary from country to country, or even from state to state,
2598 however most include the performance measures of SAIDI and often system average interruptions
2599 per mile of line.
2600 Another business approach can be to measure the quantity of Non-Distributed-Energy due to un-
2601 availability of power at consumer side. The quicker the restoration is performed after a fault, the
2602 less is the quantity of non-distributed energy.
2603

2604 5.1.2.1.2 Communications requirements

2605 The FLISR use case is divided into four sequences:
2606 1. Fault detection and clearance – The protection devices in the grid are detecting the fault
2607 and issuing suitable breaker tripping.
2608 2. Fault localization – Identify the physical location of the fault by analysing the telemetered
2609 alarms received from protection devices in the grid
2610 3. Fault isolation – Determine switching actions which will isolate the faulty equipment(s) from
2611 the rest of the grid
2612 4. System restoration (optional) – Re-supply those healthy parts of the grid, which are de-
2613 energized during the fault clearing.
2614 The execution within these steps is typically highly automated, while the continuation with the next
2615 sequence typically requires a control room operator interaction.
2616
2617 Data flow:
2618

88
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2619 • Intelligent Electronic Devices / Programmable Logic Controllers / Relays communicate

2620 through serial, Ethernet or RF Mesh
2621 • Centralized or Distributed Intelligence reachable through the WAN
2622 • Potentially P2P traffic between reclosers, sensors, feeders.
2623 • Fault Intelligence Application receiving traffic from IED/PLC
2624 • Grid State Database – collect all data
2625 • Distribution Management System – Real-Time information
2626 • Time synchronization
2627 • Support of legacy devices: Serial to IP translation
2628 • Data volume could be bytes (or higher) depending on field automation penetrations and
2629 density and inclusion of other systems such as AMI data for resolution.

2630 Table 6: FLISR communication requirements

Data use Category

Parameter Control/Protection Data Monitoring/Manage
s ment Data

Latency Low (20 ms to 2 seconds) Medium (<10 S

Data occurrence Millisecond Seconds
interval s
Method of Unicast, Unicast /multicast
Communication Multicast/Broadcast
Reliabilit High Medium
yData security High High
Data volume Bytes/Kilo bytes Kilobyte
Priorit High sMedium
yLevel assurance High Low
2631

2632 5.1.2.1.3 Proposed communication architecture setup

2633 Scenario I
2634 In this scenario it is assumed that a communication network allows for a hop by hop
2635 communication between the primary substation and all the secondary substation in between. A
2636 field area router allows the communication to the central application. The field router is typically
2637 placed in one of the primary substations although not show as such in the figure 5.1 below.

89
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

SCADA
Substation to substation network Network Operating
e.g. HV/MV PLC
Meshed RF network?
Center
SCADA OMS DMS
Field router provides WAN Grid
Connectivity to central applications Historian
State
NB: Field router could be placed in
Head End Router
one of the Primary substations
Public WAN
QoS for Backhaul Private WAN Backhaul
prioritization of (Cellular) GPRS, 3G, LTE, (Substation or POP)
DA Traffic xDSL

Field Area Router Ethernet,

WiMAX

(3) upstream/downstream
IEC 61850, (2) P2P (hop by hop mode)Smart Ethernet, Serial, PLC
or RF Mesh
IEC 60870-5-101/104
(1) P2P Meters connectivity

MV Feeder LV Feeders
X
Closed Open
Primary Break between primary and secondary Primary
Distribution substation and open switch at secondarySecondary Substations Distribution
Substation A substation. Substation B
2638
2639 Figure 19: FLISR (1) Example architecture
2640 In this scenario in Figure 5.1 above, 3 modes of communication are depicted:
2641  (1) P2P communication (1hop): secondary substation to adjacent secondary substation
2642  (2) P2P communication (multi-hop): secondary substation to non adjacent secondary
2643 substation where an intermediate substation allows to router the traffic
2644  (3) Upstream and downstream communication to a central control system via a field area
2645 router which is typically equipped with a WAN communication interface and an area
2646 network communication interface. Any of the secondary or primary substations could
2647 communicate to the central applications via this router, and the area network that connects
2648 this router.
2649
2650 For the purpose of robustness it could be recommended to deploy two field area routers: one in
2651 each substation. Dynamic IP routing allows rerouting the traffic in case of failure of one of the WAN
2652 interfaces.
2653
2654 Scenario II
2655 In this scenario, in figure 5.2, each of the secondary substations implement a (typically WAN) point
2656 to point communication interface toward the field area router: typically this can be achieved
2657 through the deployment of a cellular communication module (e.g. GPRS).
2658
2659 In this scenario the traffic from a secondary substation to a secondary substation needs to go via
2660 the field area router in a hub and spoke mode. The traffic to a central application is routed via the
2661 field area router.

90
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

SCADA
Network Operating
Center
SCADA OMS DMS
Grid
Historian
State
Head End Router

Public WAN
QoS for Backhaul Private WAN Backhaul
prioritization of (Cellular) GPRS, 3G, LTE, (Substation or POP)
DA Traffic xDSL

Hub and spoke

Field Area Router Ethernet,
WiMAX

IEC 61850,
GPRS connectivity Smart Ethernet, Serial, PLC
or RF Mesh
IEC 60870-5-101/104 Meters connectivity

MV Feeder LV Feeders
X
Closed Open
Primary Break between primary and secondary Primary
Distribution substation and open switch at secondarySecondary Substations Distribution
Substation A substation. Substation B
2662
2663 Figure 20: FLISR (2) Example architecture
2664
2665 Mapping to the SGAM model:
2666

Market
• Enterprise Networks
• Intra-Control center Networks

Enterprise • Wide and Metropolitan

DMS

•
OMS
Area Networks
IP Enterprise
networks SCADA Network
Operating Center Operation

Public WAN: GPRS, • Low-end intra substation

3G, LTE, xDSL Station • Networks
IP network
Private WAN:
RF Mesh, PLC,
Wimax
Ethernet, Fiber
Field • Field Area Networks
IEC 61850,
IEC 60870-5-101/104

Process
RTU

Customer
Generation Transmission Distribution DER
premise
2667
2668 Figure 21: FLISR Communication networks mapping to the SGAM model
2669

91
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2670 5.1.3 Tele-protection using an IP/MPLS network

2671 5.1.3.1 High level overview

2672 What is protected: lines and devices.
2673
2674 Tele-protection consists in quickly and reliably detecting a (power) network fault and then ensuring
2675 the faulty equipment is isolated before the fault has a greater effect on the power grid. Tele-
2676 protection typically applies to protection implemented between substations within the high voltage
2677 network.
2678
2679 Tele-protection systems monitor and compare conditions with distance relays at the two high
2680 voltage line ends to determine if there is a fault on the protected line section. When a fault is
2681 detected, TPR (tele-protection relay) tripping signals will activate the protection equipment
2682 (typically a circuit breaker) to isolate the affected part in the adjacent substation to prevent
2683 damages to expensive substation equipment and instability in the power system. To ensure the
2684 power system is protected, relay signals need to be transferred between distance relays without a
2685 sufficient delay so as to prevent the fault to not propagate to the other equipment & substations
2686 before the telecommunications signals reach the target equipment.
2687
2688 The end-to-end delay tolerance for relay signals with the number of cycles that can vary
2689 depending on the distance, types of relays, etc. of the electricity transmission at 60Hz (NA) or
2690 50Hz (Europe). This translates to 10msnode top node delay including time for propagation from
2691 substation to substation.
2692 This end-to-end delay includes the latency of the telecom network (IP/MPLS for the purpose of this
2693 use case) as well as the detection and activation time of the protection circuits.
2694
2695 The interface from the TPR can be G.703, E&M, RS-232, X.21, IEEE c33.67, etc.
2696
2697 Use Case Diagram
2698

2699
2700 Figure 22: Tele-protection Example architecture
2701
2702 Use Case Stakeholders
2703 1. Circuit breaker: is an automatically operated electrical switch designed to protect an electrical
2704 circuit from damage caused by overload or short circuit. Its basic function is to detect a fault
2705 condition and, by interrupting continuity, to immediately discontinue electrical flow.
2706 2. Tele-protection Relay (TPR): activate the protection equipment to isolate the affected part in
2707 adjacent substation to prevent damages to expensive substation equipment and instability in the
2708 power system

92
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2709 3. Telecommunication Equipment: interface to TPR in order to adapt and transfer control signals
2710 between the TPRs. Provides circuit emulation services in order to transport TDM based
2711 interfaces over a Packet Switched Network (PSN)
2712 4. Telecommunication network (IP/MPLS): provides packet-based communication between the
2713 Telecommunication Equipment end points. It supports the QoS and path protection
2714 mechanisms needed by the targeted services.

2715 5.1.3.2 Communications requirements

2716 The table below lists the network communication requirements for the Tele-protection scenario.
2717 Table 7: Tele-Protection communication requirements

Data Category
Parameters use
Control/Protection Data Monitoring/Manage
ment Data

Latency Less than 10ms 100ms

Data occurrence Unpredictable (based on Periodic
interval Network conditions)
Method of Unicast Unicast
Communication
Reliability Very High High
Data security High High
Data volume Few Kilo bytes Kilobytes
Priority Very High Medium
Level assurance High High
2718
2719 The following provides additional clarifications as regards the communication requirements:
2720 • The end to end latency of 10 ms includes the TDM-related packetization delay
2721 • Symmetry: The end to end delay in one direction shall not exceed the end to End delay in
2722 the other direction by more than 2ms
2723 • Resiliency: All traffic paths shall be protected, where the protection delay shall not take
2724 more than 100ms (50ms is preferred)
2725 • Denial of service: the IP/MPLS network shall support denial of service protection
2726 mechanisms in order to avoid disrupting the control plane and incurring excessive delay for
2727 the tele-protection signals
2728 • Time synchronization: The IP/MPLS network shall provide accurate time synchronization
2729 needed to support TDM services (1ms granularity)
2730 • QoS: The IP/MPLS network shall implement a Strict Priority scheduling algorithm that allow
2731 minimal delay per IP/MPLS node: the delay incurred by each traversed node shall be less
2732 than 250µs

93
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2733 5.1.3.3 Proposed communication architecture setup

Teleprotection Mechanisms for detecting a (power) network fault and then ensuring the faulty equipment is
over IP/MPLS isolated through sending teleprotection signals via an IP/MPLS network
2734
2735 High level functions
2736
0 Substation detect a fault detection
1 Substation isolates a fault by acting upon a circuit breaker
2 A Teleprotection relay sends teleprotection signals to another teleprotection relay located at
another substation
3 Telecommunication equipment provides adaptation of a TDM signal to a packet based IP/MPLS
network (and vice versa)
4 IP/MPLS network transports packetized TDM traffic
5 Circuit breaker at peer substation activated
2737
2738 Communications requirements
2739
2740  End to end latency between the egress port of the TPR and the ingress port of the other TPR shall
2741 not exceed 10 ms including the TDM packetization delay (when applicable)
2742
2743  Symmetry: The end to end delay in one direction (TPR1 to TPR2) shall not differ from the end to End
2744 delay in the other direction (TPR2 to TPR1) by more than 2ms (750 micro seconds may be preferred
2745 by some deployments)
2746
2747  Resiliency: All traffic paths shall be protected, where the protection delay shall not take more than
2748 100ms (50ms is preferred)
2749
2750  Denial of service: the IP/MPLS network shall support denial of service protection mechanisms in
2751 order to avoid disrupting the control plane and incurring excessive delay for the tele-protection signal
2752
2753  Time synchronization: The IP/MPLS network shall provide accurate time synchronization needed to
2754 support TDM services (1ms granularity)
2755
2756  QoS: The IP/MPLS network shall implement a Strict Priority scheduling algorithm that allow minimal
2757 delay per IP/MPLS node: the delay incurred by each traversed node shall be less than 250µs
2758
2759 Proposed communications architecture setup
2760
2761 The figure below provides the proposed communication architecture setup.
2762

2763
2764 Figure 23: Tele-Protection Architecture example
2765

94
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2766 In this figure the Telecommunication equipment provide TDM over packet and vice versa
2767 communication. The Edge router allows for traffic marking in order to ensure that the teleprotection
2768 traffic gets the highest scheduling priority. Additionally the Edge router allows routing the
2769 teleprotection IP packets over specific LSPs (Label Switched Paths) that are reserved for high
2770 priority traffic. Those LSPs are path protected by the Fast Reroute mechanism as described in
2771 IETF RFC 4090.
2772
2773
2774 The total end-to-end latency is calculated by summing the packetization delay (PD), network delay
2775 (ND) and jitter buffer delay (JBD) as shown in the below figure.
2776
2777 Assuming a PD of 2ms, a JBD of 4ms, the network shall be dimensioned in order to provide the
2778 remaining delay budget.
TDM Packets moving in this direction

Packet
DS1 DS1 Data GigE Switched GigE Jitter Data DS1 DS1
LIU Packetization Network Buffer LIU
Access Access
Circuit Sig (PSN) Sig
Circuit

Network
Packetization Playout
• Fixed delay
• As TDM traffic from the • TDM PW packets are
Access Circuit (AC) is • Packet transfer delay based received from the PSN and
on link speeds and distances stored into its associated
received, it is packetized from end to end
and transmitted into the configurable jitter buffer
PSN • Variable delay
• Play-out of the TDM data
• Two modes of operation: • the number of and type of back into the AC when it’s
switches at least 50% full
• CESoPSN (RFC5086) for
structured nxDS0/64k • queuing point in the
channels switches
• SAToP (RFC4553) for • QoS is key to ensure effective
unstructured T1 service delivery
2779
2780 Figure 24: Delay incurred by the telecommunication equipment and the IP/MPLS network
2781
2782
2783 - Circuit emulation: RFC 5086, RFC4553
2784 - Specific LSP(s) for tele-protection traffic: primary + backup path
2785 - Traffic marking: done at the telecommunication equipment
2786
2787 Mapping of communication networks to the SGAM model:
2788

95
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Market

Enterprise

• Inter-substation Networks
Operation
• Intra-substation Networks

IP MPLS networks Station

G.703
RS-232 Field
Ethernet
IP
Tele-protection
Relay Process

Circuit breaker
Customer
Generation Transmission Distribution DER
premise
2789
2790 Figure 25: Tele-Protection: Mapping of communication networks to the SGAM model

2791 5.1.4 Workforce communication

2792 This use case will be developed in a subsequent release.

2793 5.1.4.1 Proposed communication architecture setup

2794

Remote Workforce Management

Network Diagram

Substation Yard Substation Control Building Enterprise, Data, and

Control Center
Outdoor Hardened AP
IP WAN Traffic
Wireless Wired or Wireless § Segmentation LMS, EMS,
§ Access Control etc.
Connectivity Connectivity
§ Encryption
Circuit Breakers, § Firewall NOC
Transformers, AAA, ACS,
Indoor etc.
Capacitor Hardened AP
Banks, etc. Data Center

Engineer or
Technician with WAN
Laptop
Ethernet Private
WAN Enterprise
Edge Core Si

IPSec
Tunnel DMZ
Engineer or
Technician with
Laptop

Hardened PC
Engineer or Technician
with Laptop Internet
Fiber
NERC-CIP Electronic Security
Copper Perimeter (ESP)

2795 C97-593675-00 © 2010 Cisco Systems, Inc. All rights reserved. Cisco Confidential 22

2796 Figure 26: Workforce management example architecture

2797

96
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2798 5.2 Mapping Example Use Cases to the Conceptual Model

2799 Here is a mapping of the above Use Case examples chosen for the Communications to the Smart Grid Conceptual Model Domains, “x” means
2800 that the domain is involved in the use case.
2801 Table 8: Mapping Example use Cases to the Conceptual Model Domains
Use Case Markets Operations Services Bulk DER Transmission Distribution Customer
Generation
Demand Response 2x Use Cases emerging
- via gateway and Energy x x x (x) x x
Manager maybe. Depending on maybe. Depending DER in Customer maybe. Depending on
national split of ops. & Domain (2 meter solutions) & on national communication
BSS deregulation. deregulation. technology used.
- Smart appliances x x x (x) x x
varies on national split of maybe, depending DER in Customer maybe, depending on
ops. & BSS deregulation. Domain (2 meter solutions) & on national communication
rd
Also 3 party Appliance deregulation. technology used.
Service providers.
Distributed source of Energy x x x x x
for billing & accounting
Substation Automation Use Case not specified: covered in the Architecture
(Primary)
Electric Vehicles 2x Use Cases emerging
- Adhoc x x x x
for eBilling
- Smart Charging x x x x x x
maybe depending on maybe depending EV Storage & on
national split of ops. & national deregulation.
BSS deregulation.
Energy Trade Market Use Case not specified
Distribution Automation x x x
(Secondary)/FLISR
Wide Area Situation x x x x
Awareness - Recent
Teleprotection x
Remote workforce x x x x x
management- Recent

97
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2802 This table is based on the use cases in clause 3.1 above, these are a subset of the 450 use cases that exist in the Sustainable Process use
2803 cases repository. The items in this table are aligned with the descriptions in the repository; no attempt was made to survey all 450 use cases.
2804 There is a close relationship between the cases in this table and the descriptions in clause 3.1 above. This mapping could be viewed as a
2805 summary of the chosen use cases above. These use cases were selected as they are demonstrating the communications requirements.
2806

98
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2807 5.3 QoS requirements for different Smart Grid Applications

2808 This will be elaborated in the next version.
2809

99
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2810 6 Description of selected communication profiles for the Smart Grid

2811 communications

2812 6.1 Introduction

2813 Generally a profile defines a subset of an entity (e.g. standard, specification or a suite of
2814 standards/specifications). Profiles enable interoperability and therefore can be used to reduce the
2815 complexity of a given integration task by:
2816  Selecting or restricting standards to the essentially required content, e.g. removing options
2817 that are not used in the context of the profile
2818  By setting specific values to defined parameters (frequency bands, metrics, etc.)
2819
2820 A standard profile for communications standards may contain a selection of communication
2821 capabilities applicable for specific deployment architecture. Furthermore a profile may define
2822 instances (e.g. specific device types) and procedures (e.g. programmable logics, message
2823 sequences) in order to support interoperability.
2824
2825 It may also provide a set of engineering guidelines to ease the deployment of new technologies.
2826
2827 A standard profile may contain the following information:
2828
2829 Communication profile name
2830 Communication requirements and boundary
2831 Delay / Latency, Jitter
2832 Routing convergence time
2833 Bi directional jitter
2834 Nb of nodes
2835 BER
2836 Admissible Packet loss rate
2837 …
2838 Network diagram
2839 Drawings / Schema
2840 List of use cases / systems if relevant
2841 List of technologies
2842 Specifications / standards
2843 Security considerations
2844 Standards
2845 AAA
2846 Overall diagram
2847 Configuration parameters
2848 Best current practice
2849
2850 The following paragraphs are giving 2 examples of communication profiles. These profiles have
2851 been developed to illustrate the concept. This should be considered as example only, no validation
2852 have been performed and some pieces have not been fully developed.

2853 6.2 Profile Example 1: Field Area Network

2854 6.2.1 Communication profile name: Field Area Network

2855 The FAN may serve the following systems: smart metering, feeder automation, FLIR (Fault
2856 Location, Registration, Isolation and Restoration), EHV charging, demand response, voltage
2857 regulation, distributed generation.
2858

100
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2859 The following profile will primarily focus on 2 of these systems: Smart metering and Feeder
2860 automation. This is a multiservice network; the profile should combine the requirements from both
2861 use cases.
2862
2863 Feeder automation:
2864 A Feeder automation system refers to the system and all the elements needed to perform
2865 automated operation of components placed along the MV network itself (feeders), including
2866 (but not limited to) fault detectors, pole or ground mounted MV-switches, MV-disconnectors
2867 and MV-circuit-breakers - without or with reclosing functionality (also called reclosers) between
2868 the HV/MV substation (MV side included) and the MV/LV substations.
2869 The typical considered operations are protection functionalities (from upwards and/or
2870 distributed), service restoration (after fault conditions) or feeder reconfiguration.
2871
2872 Advanced Metering Infrastructure:
2873 This network may connect meter concentrator (NNAP) and smart meters (LNAP) in this sense, it
2874 could overlap with the Neighborhood Network. It is also use to connect the MNAP to the HES via
2875 the uplink. The AMI system or the feeder automation system may benefit from each other and
2876 share the same network infrastructure but using QOS and/or VPN technologies to differentiate
2877 the flow of data.

2878 6.2.2 Communication requirements and boundaries

Data use Category

Parameter Control/Protection Data Monitoring/Manage
s ment Data

Latency Low (20 ms to 2 seconds) Medium (<10 S

Data occurrence Millisecond Seconds
interval s
Method of Unicast, Unicast /multicast
Communication Multicast/Broadcast
Reliabilit High Medium
yData security High High
Data volume Bytes/Kilo bytes Kilobyte
Priorit High sMedium
yLevel assurance High Low
2879

2880 6.2.3 Scalability:

2881 Feeder automation: tens of nodes
2882 Smart metering: 10,000

2883 6.2.4 Network diagram

2884

101
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

SCADA
Substation to substation network Network Operating
e.g. HV/MV PLC
Meshed RF network?
Center
SCADA OMS DMS
Field router provides WAN Grid
Connectivity to central applications Historian
State
NB: Field router could be placed in
Head End Router
one of the Primary substations
Public WAN
QoS for Backhaul Private WAN Backhaul
prioritization of (Cellular) GPRS, 3G, LTE, (Substation or POP)
DA Traffic xDSL

Field Area Router Ethernet,

WiMAX

(3) upstream/downstream
IEC 61850, (2) P2P (hop by hop mode)Smart Ethernet, Serial, PLC
or RF Mesh
IEC 60870-5-101/104
(1) P2P Meters connectivity

MV Feeder LV Feeders
X
Closed Open
Primary Break between primary and secondary Primary
Distribution substation and open switch at secondarySecondary Substations Distribution
Substation A substation. Substation B
2885

2886 6.2.5 List of systems if relevant

2887 - Smart metering (NNAP, LNAP, HES communication)
2888 - Feeder automation

2889 6.2.6 List of technologies

2890 UP-link connectivity:
2891 - GPRS, 3G, LTE, xDSL, Wimax, Fiber, Ethernet
2892
2893 This profile will focus on device connectivity, which is the lower part of the network. The up-link
2894 technologies are only listed for the sake of a good understanding. It is to be noticed that some up-
2895 link technologies may be used for low-end inter-substation connectivity (802.16 for instance)
2896
2897 IPv6 is recommended due to the large number of devices to be connected.
2898
2899 Layer 3 routing: RPL (Routing over Low power and lossy network)
2900
2901 MAC/Phy: 802.15.4g (RF), P1901.2 (PLC), ETSI TS 103908 (PLC), EN 14908 (PLC)
2902 QOS
2903 VPN
2904 Multicast
2905
2906 FAN Protocol stack:
2907

102
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Layer Web Services/EXI SNMP, IPfix, IEC 61968 CIM

App.
IEEE
DNS, NTP, ANSI C12.19/C12.22 IEC 61850 IEC 60870 DNP EN50090 MODBUS
1588
HTTPS/CoAP SSH,… DLMS/COSEM, M&M, OSGP

TCP/UDP
Functionality
Network
Comm. Network Layer

Routing – RPL IPv6 / IPv4 Addressing, Multicast, QoS, Security

Access control and security layer

6LoWPAN (RFC 6282) IETF RFC 2464 ETSI 102 887-2 IETF RFC 5072 IETF RFC 5121
Functionality
PHY / MAC

IEEE 802.15.4 802.15.4e MAC enhancements

MAC IEEE 802.15.4 IEEE
MAC (including FHSS) P1901.2 IEEE 802.3 IEEE 802.16
ETSI 102 887-1 2G / 3G / LTE
IEEE 802.15.4 IEEE 802.15.4g Ethernet WiMax
Cellular
2.4GHz DSSS (FSK, DSSS, OFDM)
2908
2909
2910 The profile is focusing on the light orange part of the figure. The different MAC/PHY may imply the
2911 development of different sub-profiles as MAC/PHY specificities may lead to different configuration
2912 parameters in the upper communication layers.

2913 6.2.7 Specifications / standards

2914 This paragraph should give the list of all relevant standards used for implementing the profile.

2915 6.2.8 Security considerations

2916 Access control:
2917 802.1x
2918 EAP
2919 Security encryption:
2920 TLS
2921 DTLS

2922 6.2.9 Configuration parameters

2923 6.2.9.1 IPv6 addressing scheme

2924 Manual configuration
2925 This is appropriate for Head-End and NMS servers that never change their address, but is
2926 inappropriate to millions of end-points, such as meters, in regards to the associated operational
2927 cost and complexity. This may be used for the feeder automation as the number of devices will be
2928 limited but not recommended.
2929
2930 Stateless auto-configuration
2931 An IPv6 prefix gets configured on a router interface (interface of any routing device such as a
2932 meter in a mesh or PLC AMI network), which is then advertised to nodes attached to the interface.
2933 When receiving the prefix at boot time, the node can automatically set-up its IPv6 address
2934
2935 Stateful auto-configuration
2936 Through the use of DHCPv6 Individual Address Assignment, this method requires DHCPv6 Server
2937 and Relay to be configured in the network but benefits of a strong security as the DHCPv6 process
2938 can be coupled with AAA authentication, population of Naming Services (DNS) available for Head-
2939 End and NMS applications. The list above is the minimum set of tasks to be performed, but as
2940 already indicated; you must also establish internal policies and operational design rules. This is
2941 particularly true when considering security and management tasks such as registering IPv6
2942 addresses and names in DNS (Domain Name System) and in NMS (network management
2943 station(s) or setting-up filtering and firewalling across the infrastructure.
2944

103
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2945 6.2.9.2 Routing protocol:

2946 RPL Profile
2947 This section outlines a RPL profile for a representative AMI and Feeder automation
2948 deployment.
2949
2950 (Source: Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL)
2951 in AMI Networks draft-ietf-roll-applicability-ami-05)

2952 6.2.9.2.1 RPL Features

2953 6.2.9.2.1.1 RPL Instances

2954 RPL operation is defined for a single RPL instance. However, multiple RPL instances can be
2955 supported in multi-service networks where different applications may require the use of different
2956 routing metrics and constraints, e.g., a network carrying both Smart Metering data and feeder
2957 automation traffic.
2958
2959 We may need to define one instance per application. This allows taking into account the specific
2960 requirements of each application (QOS, delay, jitter…) and allowing RPL to establish one topology
2961 per RPL instance (i.e. application).

2962 6.2.9.2.1.2 Storing vs. Non-Storing Mode

2963 In most scenarios, electric meters are powered by the grid they are monitoring and are not
2964 energy-constrained. Instead, electric meters have hardware and communication capacity
2965 constraints that are primarily determined by cost, and secondarily by power consumption. As a
2966 result, different AMI deployments can vary significantly in terms of memory size, computation
2967 power and communication capabilities.
2968
2969 For this reason, the use of RPL storing or non-storing mode SHOULD be deployment specific.
2970 When meters are memory constrained and cannot adequately store the route tables necessary to
2971 support hop-by-hop routing, RPL non-storing mode SHOULD be preferred. On the other hand,
2972 when nodes are capable of storing such routing tables, the use of storing mode may lead to
2973 reduced overhead and route repair latency.
2974
2975 However, in high-density environments, storing routes can be challenging because some nodes
2976 may have to maintain routing information for a large number of descendants. When the routing
2977 table size becomes challenging, it is RECOMMENDED that nodes perform route aggregation,
2978 similarly to the approach taken by other routing protocols, although the required set of mechanism
2979 may differ.

2980 6.2.9.2.1.3 DAO Policy

2981 Two-way communication is a requirement in AMI systems. As a result, nodes SHOULD send
2982 DAO messages to establish downward paths from the root to them.

2983 6.2.9.2.1.4 Path Metrics

2984 Smart metering deployments utilize link technologies that may exhibit significant packet loss and
2985 thus require routing metrics that take packet loss into account. To characterize a path over such
2986 link technologies, AMI deployments can use the Expected Transmission Count (ETX) metric as
2987 defined in [I-D.ietf-roll-routing-metrics]. For water- and gas-only networks that do not rely on
2988 powered infrastructure, simpler metrics that require less energy to compute would be more
2989 appropriate. In particular, a combination of hop count and link quality can satisfy this requirement.
2990
2991 As minimizing energy consumption is critical in these types of networks, available node energy
2992 should also be used in conjunction with these two metrics. The usage of additional metrics

104
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

2993 specifically designed for such networks may be defined in companion RFCs, e.g., [I-D.ietf-roll-
2994 routing-metrics] .

2995 6.2.9.2.1.5 Objective Function

2996 RPL relies on an Objective Function for selecting parents and computing path costs and rank.
2997 This objective function is decoupled from the core RPL mechanisms and also from the metrics in
2998 use in the network. Two objective functions for RPL have been defined at the time of this writing,
2999 OF0 and MRHOF, both of which define the selection of a preferred parent and backup parents,
3000 and are suitable for AMI deployments.
3001
3002 Neither of the currently defined objective functions supports multiple metrics that might be required
3003 in heterogeneous networks (e.g., networks composed of devices with different energy constraints)
3004 or combination of metrics that might be required for water- and gas-only networks. Additional
3005 objective functions specifically designed for such networks may be defined in companion RFCs

3006 6.2.9.2.1.6 DODAG Repair

3007 To effectively handle time-varying link characteristics and availability, AMI deployments SHOULD
3008 utilize the local repair mechanisms in RPL. Local repair is triggered by broken link detection and in
3009 storing mode by loop detection as well. The first local repair mechanism consists of a node
3010 detaching from a DODAG and then re-attaching to the same or to a different DODAG at a later
3011 time. While detached, a node advertises an infinite rank value so that its children can select a
3012 different parent. This process is known as poisoning and is described in Section 8.2.2.5 of [I-D.ietf-
3013 roll-rpl].
3014
3015 While RPL provides an option to form a local DODAG, doing so in AMI deployments is of little
3016 benefit since AMI applications typically communicate through a LBR. After the detached node has
3017 made sufficient effort to send notification to its children that it is detached, the node can rejoin the
3018 same DODAG with a higher rank value. The configured duration of the poisoning mechanism
3019 needs to take into account the disconnection time applications running over the network can
3020 tolerate. Note that when joining a different DODAG, the node need not perform poisoning. The
3021 second local repair mechanism controls how much a node can increase its rank within a given
3022 DODAG Version (e.g., after detaching from the DODAG as a result of broken link or loop
3023 detection). Setting the DAGMaxRankIncrease to a non-zero value enables this mechanism, and
3024 setting it to a value of less than infinity limits the cost of count-to-infinity scenarios when they occur,
3025 thus controlling the duration of disconnection applications may experience.

3026 6.2.9.2.1.7 Multicast

3027 RPL defines multicast support for its storing mode of operation, where the DODAG structure built
3028 for unicast packet dissemination is used for multicast distribution as well. In particular, multicast
3029 forwarding state creation is done through DAO messages with multicast target options sent along
3030 the DODAG towards the root. Thereafter nodes with forwarding state for a particular group forward
3031 multicast packets along the DODAG by copying them to all children from which they have received
3032 a DAO with a multicast target option for the group. Multicast support for RPL in non-storing mode
3033 will be defined in companion RFCs.

3034 6.2.9.2.1.8 Security

3035 AMI deployments operate in areas that do not provide any physical security. For this reason, the
3036 link layer, transport layer and application layer technologies utilized within AMI networks typically
3037 provide security mechanisms to ensure authentication, confidentiality, integrity, and freshness. As
3038 a result, AMI deployments may not need to implement RPL's security mechanisms and could rely
3039 on link layer and higher layer security features.

105
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

3040 6.2.9.2.1.9 P2P communications

3041 Distribution Automation and other emerging applications may require efficient P2P
3042 communications. Basic P2P capabilities are already defined in the RPL RFC [I-D.ietf-roll-rpl].
3043 Additional mechanisms for efficient P2P communication are being developed in companion RFCs.

3044 6.2.9.2.2 Recommended Configuration Defaults and Ranges

3045 6.2.9.2.2.1 Trickle Parameters

3046 Trickle was designed to be density-aware and perform well in networks characterized by a wide
3047 range of node densities. The combination of DIO packet suppression and adaptive timers for
3048 sending updates allows Trickle to perform well in both sparse and dense environments. Node
3049 densities in AMI deployments can vary greatly, from nodes having only one or a handful of
3050 neighbors to nodes having several hundred neighbors. In high density environments, relatively low
3051 values for Imin may cause a short period of congestion when an inconsistency is detected and DIO
3052 updates are sent by a large number of neighboring nodes nearly simultaneously.
3053
3054 While the Trickle timer will exponentially backoff, some time may elapse before the congestion
3055 subsides. While some link layers employ contention mechanisms that attempt to avoid congestion,
3056 relying solely on the link layer to avoid congestion caused by a large number of DIO updates can
3057 result in increased communication latency for other control and data traffic in the network. To
3058 mitigate this kind of short-term congestion, this document recommends a more conservative set of
3059 values for the Trickle parameters than those specified in [RFC6206]. In particular, DIOIntervalMin
3060 is set to a larger value to avoid periods of congestion in dense environments, and
3061 DIORefundancyConstant is parameterized accordingly as described below.
3062
3063 These values are appropriate for the timely distribution of DIO updates in both sparse and dense
3064 scenarios while avoiding the short-term congestion that might arise in dense scenarios. Because
3065 the actual link capacity depends on the particular link technology used within an AMI deployment,
3066 the Trickle parameters are specified in terms of the link's maximum capacity for transmitting link-
3067 local multicast messages. If the link can transmit m link-local multicast packets per second on
3068 average, the expected time it takes to transmit a link-local multicast packet is 1/m seconds.
3069 DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that the Trickle Imin is at
3070 least 50 times as long as it takes to transmit a link-local multicast packet.
3071
3072 This value is larger than that recommended in [RFC6206] to avoid congestion in dense urban
3073 deployments as described above. In energy-constrained deployments (e.g., in water and gas
3074 battery-based routing infrastructure), DIOIntervalMin MAY be set to a value resulting in a Trickle
3075 Imin of several (e.g. 2) hours. DIOIntervalDoublings: AMI deployments SHOULD set
3076 DIOIntervalDoublings such that the Trickle Imax is at least 2 hours or more. For very energy
3077 constrained deployments (e.g., water and gas battery-based routing infrastructure),
3078 DIOIntervalDoublings MAY be set to a value resulting in a Trickle Imax of several (e.g., 2) days.
3079 DIORedundancyConstant: AMI deployments SHOULD set DIORedundancyConstant to a value of
3080 at least 10. This is due to the larger chosen value for DIOIntervalMin and the proportional
3081 relationship between Imin and k suggested in [RFC6206].
3082
3083 This increase is intended to compensate for the increased communication latency of DIO updates
3084 caused by the increase in the DIOIntervalMin value, though the proportional relationship between
3085 Imin and k suggested in [RFC6206] is not preserved. Instead, DIORedundancyConstant is set to a
3086 lower value in order to reduce the number of packet transmissions in dense environments.

3087 6.2.9.2.2.2 Other Parameters

3088 AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in 8 bits of resolution
3089 (e.g., for the ETX metric).

106
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

3090 To enable local repair, AMI deployments SHOULD set MaxRankIncrease to a value that
3091 allows a device to move a small number of hops away from the root. With a
3092 MinHopRankIncrease of 256, a MaxRankIncrease of 1024 would allow a device to move up
3093 to 4 hops away.

3094 6.2.10 MAC / PHY configuration parameters:

3095 According to the MAC/PHY chosen, you will find here the frequency band, the different parameters
3096 to configure the MAC and Physical layer with the default values.

3097 6.2.11 Best current practice:

3098 This paragraph may describe some largely deployed solutions using this profile with the
3099 parameter’s default values, the scalability number and any useful information.

3100 6.3 Profile Example 2: IP MPLS

3101 6.3.1 Introduction

3102 This communication profile considers the case where an IP/MPLS network is used as WAN
3103 communications network to interconnect substations (to each other), Utility control center and Bulk
3104 power stations.
3105
3106 In particular the focus of this profile is on the use of the IP/MPLS network for the purpose of inter-
3107 substation Teleprotection. The same IP/MPLS network can be used for other smart grid
3108 communications.
3109
3110 The communication architecture considered for this profile is depicted in the figure below:
3111
Bulk generation Data and control center

Substation Substation

IP/MPLS network

3112
3113 Figure 27: Architecture for IP/MPLS based teleprotection
3114 For the sake of simplicity only two substations are depicted in this architecture; however the
3115 described profile is applicable to an arbitrary number of substations sharing the same IP/MPLS
3116 infrastructure.
3117
3118 The IP/MPLS network can either be owned operated and managed by the Energy provider or
3119 communication network operator.

3120 6.3.2 Communication requirements and boundaries

3121 The following requirements shall be fulfilled by the communications network.
3122
3123  The End to end latency between the egress port of the TPR and the ingress port of the
3124 other TPR shall not exceed 10 ms. This delay includes the TDM packetization delay (when
3125 applicable).

107
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

3126
3127  Symmetrical delay: The end to end delay in one direction (TPR1 to TPR2) shall not differ
3128 from the end to End delay in the other direction (TPR2 to TPR1) by more than 2ms.
3129
3130  Security/Denial of service attacks: the IP/MPLS network shall support denial of service
3131 protection mechanisms in order to avoid disrupting the control plane and incurring
3132 excessive delay for the tele-protection signal
3133
3134  Time synchronisation: The IP/MPLS network shall provide accurate time synchronisation
3135 needed to support TDM services
3136
3137  QoS: The IP/MPLS network shall implement a Priority scheduling algorithm that allows for
3138 minimal delay per IP/MPLS node

3139 6.3.3 Detailed Network diagram for the profile

3140 End-to-End Layer 1 and Layer 2 communications services over MPLS are shown in the figure
3141 below:

3142
3143 Figure 28: MPLS services
3144 The choice of VPLS or VPWS for the purpose of our profile depends on the interface that is
3145 implemented by the TPR.

3146 6.3.3.1 The TPR implements an Ethernet interface

3147 In case the TPR implements an Ethernet Interface, a VPLS (Virtual Private LAN Service) service
3148 as defined in RFC 4762 is preferred because it allows a multipoint to multipoint connectivity. VPLS
3149 is a Layer 2 VPN (Virtual Private Network) service and is used to provide multi-point to multi-point
3150 Ethernet connectivity between the TPRs (for the purpose of teleprotection) and for the overall
3151 communication between the substations, the data and control center and the bulk generation sites.
3152 VPLS emulates an Ethernet bridge connecting these endpoints. In a converged MPLS network,
3153 this Layer 2 VPN is achieved using a full mesh of LSPs between the participating sites.
3154 Conceptually, a number of secure tunnels are constructed, allowing multipoint connectivity.

108
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

Bulk generation Data and control center

Substation TPR1 TPR2 Substation

Fully meshed MPLS network supporting VPLS
All nodes implement strict priority queuing

Traffic marking – Traffic marking –

RFC 3270 IP/MPLS network RFC 3270
VPLS service – VPLS service –
RFC 4762 RFC 4762
3155
3156 Figure 29: Teleprotection using VPLS (Ethernet TPRs)
3157 For the sake of simplicity, Figure 4 shows a partial view representing a point to point VPLS
3158 connecting the substation TPRs.

3159 6.3.3.2 The TPR implements a TDM interface

3160 In case the TPR implements a TDM interface, a circuit emulation service is required. Two modes of
3161 circuit emulation can be supported (depending on the TDM interfaces): unstructured and
3162 structured.
3163  Unstructured mode is supported for DS1 and E1 channels per RFC 4553, Structure-
3164 Agnostic Time Division Multiplexing (TDM) over Packet (SAToP).
3165  Structured mode is supported for n*64 kbps circuits as per RFC 5086, Structure-Aware
3166 Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network
3167 (CESoPSN).
3168
3169 Both circuit emulation services (structured and unstructured), a VPWS (Virtual Pseudo Wire
3170 Service) service as defined in RFC 4447 should be used. In VPWS a pseudo-wire is a point-to-
3171 point connection between two end points: the TPRs in this case. Circuit/TDM services can be
3172 carried over MPLS pseudo wires.
3173
Bulk generation Data and control center

Substation TPR1 TPR2 Substation

Fully meshed MPLS network supporting VPWS
All nodes implement strict priority queuing

Traffic marking - RFC 3270 Traffic marking - RFC 3270

CESoPSN – RFC 5086 IP/MPLS network CESoPSN – RFC 5086
SAToP – RFC 4553 SAToP – RFC 4553
VPWS – RFC 4447 VPWS – RFC 4447
3174
3175 Figure 30: Teleprotection using VPWS (TDM TPR)
3176

109
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

3177 In Figure 30, the MPLS edge router (also referred to as Provide Edger - PE- router) must
3178 implement a circuit emulation mechanism to allow the transport of a circuit/TDM interface over the
3179 IP/MPLS network. Depending on the type of the TDM interface RFC 4553 or RFC 5086 can be
3180 used.

3181 6.3.3.3 Path protection

3182 MPLS Fast Reroute provides path protection mechanisms where the switching time is estimated at
3183 50 ms. For the purpose of Teleprotection which mandates a delay bound of 10 ms, Fast Reroute
3184 does not provide an adequate answer.

3185 To provide 10 ms protection, two separate MPLS LSP paths should be provisioned and used by
3186 the TPRs to send teleprotection signals simultaneously over the two LSPs. The same protection
3187 mechanism can be used for both the VPLS and the VPWS as depicture in Figure 31 below:

Bulk generation Data and control center

Substation TPR1 TPR2 Substation

Interface 1 Interface 2 LSP2 used to send teleprotection

signals from TPR1/interface 2

LSP1 used to send teleprotection

signals from TPR1/interface 1

3188
3189 Figure 31: Achieving protection for Teleprotection services.

3190 6.3.3.4 Quality of Service and scheduling

3191 The IP/MPLS network shall support the DiffServ QoS architectural model mapped to MPLS as
3192 defined in RFC 3270

3193 6.3.3.5 Achieving path symmetry

3194 To achieve path symmetry the network should support IP/MPLS traffic engineering capabilities as
3195 defined in RFC 3209 for RSVP-TE.

3196 The path in each directed is determined (traffic engineered) offline and provided to the ingress PE
3197 (Provider Edge) routers to set the LSP according to an explicit route. The explicit route in one
3198 direction and in the other direction shall provide comparable end to end delay (with a tolerance of
3199 2ms) and shall take into account the packetization delay if applicable (VPWS case).

3200 Editor’s note: optionally OSPF-TE as defined in RFC 3639 and IS-IS TE as defined in RFC 3784
3201 can be used to allow for Shared Risk Link Group (SRLG) based LSP path diversity. This use if for
3202 further study

3203 6.3.3.6 Timing and synchronisation

3204 In order to support TDM service (TPRs supporting TDM interfaces) the PE router must support
3205 timing and synchronization as specified in: ANSI T1.403 and ITU-T G.2861

110
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

3206 6.3.3.7 System reliability

3207 System reliability is generally achieved through redundancy; therefore, the network equipment
3208 must provide redundant cooling, and redundant power.

3209 For continuity of service, functions such as non-stop-signaling and non-stop routing and an intra-
3210 nodal high availability control plane failover mechanism must be supported for all active services.
3211 The deployed system shall support both hardware and software redundancy.

3212 Hardware redundancy:

3213  Component redundancy
3214  Dual switching fabric
3215  Redundant cooling system
3216  Redundant power

3217 Software redundancy

3218  Configuration Redundancy
3219  Service Redundancy
3220  Accounting Configuration Redundancy
3221  Synchronization

3222 6.3.3.8 Network reliability

3223 The network equipment forming the solution must embody the following reliability traits.
3224  Inter-nodal failover with multi-chassis APS for CES, IP/MPLS and MLPPP (IP)
3225  Multiple link, card, and node fault restoration scenarios
3226  Pseudowire redundancy protection for IP/MPLS, as specified in RFC 5254
3227  CES, ETH over redundant pseudowires

3228 With the evolution towards IP/MPLS, devices providing the aggregation layer for a significant
3229 proportion of revenue generating services, having a single point of failure at the core layer may
3230 cause a significant loss of revenue. Multi-chassis developments have effectively removed that
3231 single point of failure. Multi-chassis support can be extended to both Ethernet and SDH interfaces.

3232 6.4 Initial list of profiles for future development by SDOs

3233 The following list gives a first outlook of different communication profiles. This list is not exhaustive
3234 and do not represent the complete scope of smart grid system needs:
3235
3236  Neighborhood Area: smart metering, EHV charging, demand response, voltage regulation,
3237 street lighting, transformer management, distributed generation
3238
3239  FAN: smart metering, feeder automation, FLIR (Fault Location, Registration, Isolation and
3240 Restoration), EHV charging, demand response, voltage regulation, distributed generation
3241
3242  Low-end intra substation Ethernet: Substation automation, Distributed Energy Resources,
3243 asset management, energy storage
3244
3245  Intra substation Ethernet based: Substation automation, Distributed Energy Resources,
3246 asset management, energy storage, synchrophasor, WAMS, WASA

111
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

3247
3248  Inter substation: Transmission Grid Management, Distribution Grid Management,
3249 Distributed Energy Resources, asset management, energy storage, synchrophasor,
3250 WAMS, WASA
3251  …

3252 6.5 Interoperability consideration/recommendations

3253 The goal of developing communication profiles is to ensure interoperability as defined in the
3254 Reference Architecture document (SG CG RA document paragraph 5.1 “Interoperability in the
3255 context of the Smart Grid”). It is aligned with the GridWise Alliance GWAC stack.
3256
3257

112
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

3258 7 Communication architecture topologies for the Smart Grid

3259
3260 This section aims at providing detailed architecture topologies for the communications networks as
3261 listed in section 1.3.

3262 7.1 Subscriber Access Network

3263 To be developed in a subsequent release

3264 7.2 Neighborhood Network

3265 To be developed in a subsequent release

3266 7.3 Field Area Network

3267 To be developed in a subsequent release

3268 7.4 Low-end intra-substation network

3269 To be developed in a subsequent release

3270 7.5 Intra-substation network

3271 Currently communication within most substations is limited to SCADA. IEDs and RTUs in the
3272 substation use point-to-point communication between them, often through a “data concentrator”.
3273 Most protocols are proprietary. The SCADA communication link between the substation and the
3274 SCADA control center are often point to point TDM connections.
3275
3276 If there are other applications located at the substations (such as teleprotection, synchrophasors,
3277 and CCTV), they each have a separate communication links to their respective counterparts.
3278
3279 The substation LAN evolution will be on two different levels. At one level, the substation
3280 architecture of the utility operations applications such as SCADA and teleprotection will evolve to
3281 the architecture specified in the IEC 61850 standard [4]. On another level, traffic generated by
3282 many new smart grid and other applications that will be resident at the substation such as the
3283 meter concentrators and CCTV will be aggregated at the substation router along with the SCADA
3284 and other operations traffic. The substation router is an ER in our integrated architecture of Figure
3285 32. The router at a (large) substation may additionally aggregate traffic generated in the vicinity of
3286 the substation.
3287

113
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

3288
3289 Figure 32: Substation communication architecture example
3290 IEC 61850 define a process bus that is an Ethernet bus. All SCADA IEDs and optionally the
3291 teleprotection IEDs and PMUs connect to the process bus. For legacy equipment gateways may
3292 be used to connect into the process bus. There may be more than one process bus.
3293
3294 The station bus is used to connect the process busses as well as other operation systems such as
3295 the distribution automation traffic concentration from the feeder IEDs (if thus designed).
3296
3297 Access to all these operation elements are protected by protecting the station bus behind firewall
3298 and/or Intrusion detection and protection (IDS/IPS) systems.
3299
3300 The substation may use another Ethernet network for connecting other smart grid and utility
3301 systems such as the CCTV, meter concentrators, and demand response systems; access to these
3302 systems is protected by another firewall and/or IDS/IPS system.
3303
3304 Finally the substation router aggregates all traffic generated at the substation and possibly traffic
3305 generated at (smaller) substations in the vicinity as well as traffic from other endpoints in the
3306 vicinity – examples of which are shown in Figure 32.

3307 7.6 Inter substation network

3308 7.6.1 High voltage teleprotection network

3309 To be developed in a subsequent release.

3310 7.6.2 Medium voltage inter-substation network

3311 The following figure provides a typical European Grid topology, source KEMA report.
3312

114
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

3313
3314 Figure 33: Distribution grid: typical substation topology for European markets (Source
3315 Kema)
3316 In this topology one can distinguish the ring topology that connects a primary distribution
3317 substation as part of the distribution network together with the secondary substations. Two cases
3318 can be distinguished:
3319  Urban areas: The primary substation connects to the secondary substations using a ring
3320 topology. Often the ring is based on an open ring, through acting on a breaker switch
3321 connecting a secondary substation.
3322  Rural areas: the primary substation connects to the secondary substation using a bus
3323 topology.

3324 7.6.3 MV Substation to substation communication topology: Point to Multipoint (P2MP)

3325 using BPL
3326 Figure X below provides an example of a Point to Multipoint topology that can be used for
3327 communication between a primary substation and the secondary substation. This topology uses
3328 MV BPL standards where each substation is equipped with a single MV BPL modem. This
3329 architecture assumes that a L2 frame sent on the communication bus is received by the entire
3330 substation but handled only by the substation has the correct destination address of the L2 frame
3331 (similar to Ethernet in bus topologies).
3332
3333 The advantage of such a topology is the reduced cost because a single MV BPL is deployed.
3334 However, it has two main disadvantages:
3335  Disconnection of the power cable will cut the communication
3336  Switching will change the impedance of the cable and degrades the communication
3337 performance
3338
3339 It can be advocated for Hub and Spoke topologies (star) or in bus technologies (rural areas).
3340

115
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

3341
3342 Figure 34: MV communication using MV BPL model, Point to multipoint topology

3343 7.6.4 MV Substation to substation communication topology: Point to Point (P2P) using
3344 BPL
3345 Figure X below provides an example of a Point to Point topology that can be used for
3346 communication between a primary substation and the secondary substation. This topology uses
3347 MV BPL standards where each substation is equipped with a two MV BPL modems.
3348
3349 Compared to the topology presented in 7.6.3, this incurs additional cost pertaining to the use of an
3350 additional BPL modem. The main advantages of this topology are:
3351  Disconnection of the power cable will NOT cut the communication
3352  No degrades to the communication performance on switching
3353
3354 It can be advocated for ring (including open ring) topologies for urban deployments.
3355

3356
3357 Figure 35: MV communication using MV BPL model, Point to point topology

3358 7.7 Intra Control Centre / Intra Data centre Network

3359 To be developed in a subsequent release
3360

116
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

3361 7.8 Enterprise Network

3362 To be developed in a subsequent release

3363 7.9 Balancing Network

3364 To be developed in a subsequent release

3365 7.10 Interchange Network

3366 To be developed in a subsequent release

3367 7.11 Trans-Regional – Trans-National Network

3368 To be developed in a subsequent release

3369 7.12 Wide and Metropolitan Area Network

3370 To be developed in a subsequent release
3371

117
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

3372 8 Security
3373 Coupling data communications capabilities with the power transmission, distribution, and
3374 consumption infrastructures increases the efficiency of the power grid, but also creates a long list
3375 of operational challenges— Security tops that list. Thus, security represents a key challenge for
3376 enabling a successful rollout of Smart Grids and AMIs. It needs to be addressed in a holistic,
3377 end-to-end fashion, leveraging the concept of “Security by Design”.
3378
3379 In the past it was sometimes claimed that the use of open standards and protocols may itself
3380 represent a security issue, but this is overcome by the largest possible community effort,
3381 knowledge database and solutions available for monitoring, analyzing and fixing flaws and
3382 threats—something a proprietary system could never achieve.
3383
3384 Said otherwise, a private network, IP-based architecture based on open standards has the best
3385 understood and remedied set of threat models and attack types that have taken place and have
3386 been remedied against, on the open Internet. This is the strongest negation of the now deprecated
3387 concept of “security by obscurity” that argues that the use of non-standard networking protocols
3388 increases security and which is unanimously rejected by the network security expert community.
3389 Security per se is not a new topic to utilities as they are already operating and maintaining large-
3390 scale data communication networks. Using IP as a common technology in the core of Smart Grids
3391 and AMIs will help to ensure security knowledge is available within the involved organizations.
3392
3393 It is important to note that IPv6 security has at least the same strengths as IPv4, but both IPv4 and
3394 IPv6 are certainly not worse than proprietary networking protocols. We recommend people
3395 focusing on FAN security to review documents such as NISTIR 7628, Guidelines for Smart Grid
3396 Cyber Security or UCAIUG, AMI System Security Requirements. In Europe, Smart Grid Information
3397 Security requirements are currently under definition by the standardization organizations; several
3398 guidelines and requirements have been issued or are under definition by the Member States. All
3399 are asking for open standards. With Security being a multi-layer challenge, it is important to review
3400 some additional features that provide nodes authentication and data integrity and privacy on a FAN
3401 deployment.
3402
3403 Strong authentication of nodes can be achieved by leveraging a set of open standards
3404 mechanisms. For example, after a node discovered a RF or PLC Mesh network leveraging IEEE
3405 802.15e enhanced Beacon frames, it can get properly authenticated through IEEE 802.1x, PKI,
3406 certificate and AAA/Radius mechanisms before beginning to communicate using a Link-local IPv6
3407 address. From there, the node can join its RPL domain before getting a global IPv6 address
3408 through DHCPv6 as well as other information (DNS server, NMS, etc.).
3409
3410 Data integrity and privacy leverages the encryption mechanisms available at various layers of the
3411 communication stack. For example, an IPv6 node on a last mile subnet has options to encrypt data
3412 at layer 2 (AES-128 on IEEE 802.15.4g or IEEE P1901.2), layer 3 (IPsec), layer 4 (DTLS) or per
3413 application at layer 7, i.e.: encryption of ANSI C12.22 or DLMS/COSEM for the metering traffic.
3414 While multiple levels of encryption may be implemented on a constraint node, the processing
3415 resources (processor speed and memory, energy consumption) requirements must be evaluated in
3416 regards of the additional hardware cost this could generate. With multiple options available it can
3417 be assured that nodes can be integrated into existing security architectures, relying on Link,
3418 Transport and/or Application Layer encryption. Furthermore, this will ease the integration and
3419 enhancement of existing Application Layer protocols (i.e. ANSI C12.22 or DLMS/COSEM) where
3420 certain security functions could convert at a lower layer, e.g. by providing a secured end-to-end
3421 path, and where other functionalities (i.e. message integrity / proof of origin) can remain at the
3422 Application Layer.
3423
3424 The choice of a given layer for data encryption and devices performing the encryption also impact
3425 the network services, performances and scalability of a deployment. For example, when software

118
 Smart Grids Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture
Annex F – Communication Architecture

3426 upgrade, demand/response or dynamic pricing should use Multicasting, the choice of encrypting
3427 data at transport layer (L4 DTLS) precludes leveraging the replication capabilities of IP Multicast
3428 routers on the infrastructure.
3429
3430 Whatever the encryption layer selected on the NAN devices, an IP Edge router can also perform
3431 Layer 3 encryption (IPsec) for all traffic forwarded over the backhaul links. Therefore, hardware
3432 cost and resources may limit to layer 2 authentication and encryption and potentially encryption at
3433 layer 3 or 7 on constrained devices while Layer 3 encryption on the IP Edge router takes care of all
3434 traffic sent over the WAN without loosing network services capabilities.
3435
3436 Combined with more traditional security features such as digital signatures for firmware images or
3437 data objects on devices (i.e. for meter reads or critical commands), traffic filtering, firewalling and
3438 intrusion prevention on the IP Edge routers, the last mile of a Smart Grid deployment can get
3439 strong security reinforcement whatever the traffic patterns.
3440
3441 With IP offering the possibility of end-to-end communication down to the last mile, also, in case this
3442 is required, end-to-end encryption can be established in an efficient manner. Moreover, Application
3443 Layer protocol translation would not be required within the communication network. Multiple
3444 protocols do not have to be maintained, this would represent a clear advantage for the efficiency
3445 and security of the network.
3446
3447 In addition, IP, as well known technology, offers already available, tested, certified software stacks,
3448 implementing proven security algorithms and Computer Security Incident Response Teams
3449 (CSIRTs) and Computer Emergency Response Team (CERT)). Thus, the Security of Smart Grids
3450 and AMIs can directly benefit from security findings within the Internet Community, now and in the
3451 future.
3452

119
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Appendix A
Industry Fora and Alliances References
3453 This Appendix references Industry Fora and Alliances documentation for information purpose only.
3454
3455 Power Line Technologies:
3456
3457 Narrow band:
3458

3459
3460
3461 Broadband:
3462

3463
3464

120
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

Appendix B
Relationship to the SGAM model
3465
3466 This section provides a mapping of the communication architecture to the SGAM model. Such a
3467 mapping is performed using the tele-protection use case.
3468
3469 The SGAM is a framework for:
3470  Hosting functional and information architectures in appropriate layers
3471  Identify top-level elements
3472  Fit in EU high level functions
3473  Map architectures to smart grid plane (domains/zones)
3474
3475 The component layer of SGAM is the physical distribution of all participating components in the
3476 smart grid context. This includes power system equipment (typically located at process and field
3477 level), protection and tele-control devices, network infrastructure (wired / wireless communication
3478 connections, routers, switches, servers) and any kind of computers
3479
3480 The Figure below provides the component layer pertaining to the Tele-protection use case. The
3481 Figure depicts the following main components
3482  Process components:
3483 o The circuit breaker: an automatically operated electrical switch designed to protect
3484 an electrical circuit from damage caused by overload or short circuit. Its basic
3485 function is to detect a fault condition and, by interrupting continuity, to immediately
3486 discontinue electrical flow.
3487  Field components:
3488 o Protection Relay: activate the protection equipment to isolate the affected part in
3489 adjacent substation to prevent damages to expensive substation equipment and
3490 instability in the power system
3491 o Gateway: interface to Protection Relay in order to adapt and transfer control signals
3492 between the Protection Relays. Provides circuit emulation services in order to
3493 transport TDM based interfaces over a Packet Switched Network (PSN), in the case
3494 of IP WAN infrastructure
3495 o WAN infrastructure: Provides reliable and low delay/jitter transport of the protection
3496 signals. This WAN infrastructure might be different from the one used to connect a
3497 substation to central control systems.
3498  The Station components:
3499 o Station controller: provide communication toward the central operation systems via
3500 a WAN infrastructure.
3501

121
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

3502
3503
3504 The Communication layer as depicted in the figure below provides the list of standards applicable
3505 for the communication stack of the Teleprotection use case.
3506
3507 The Figure depicts the following list of applicable standards:
3508  IEC 61850-8-1 (Goose)
3509  IEC 61850-9-2 (Sampled Values)
3510  IEC 61850-90-1 (SS-SS Com.)
3511  IEC 62351 (E2E Security)
3512

3513
3514
3515
3516 The figure below provides the Information layer pertaining to the Teleprotection use case. These
3517 are:
3518  IEC 61850-7-2/3/4 (Services, Data Models)
3519  IEC 61850-90-1 (SS-SS Com.)
3520  IEC 62351 (E2E Security)
3521

122
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

3522
3523
3524 The figure below provides the function layer pertaining to the Teleprotection use case. The
3525 different functions shown are:
3526  Supervision performed at the central operations systems
3527  DAQ, Supervision and Control
3528  Secure Information exchange
3529  Protection
3530

3531
3532
3533 Finally, the Business layer provides the business objectives pertaining to the use case.

123
 Smart Grid Coordination Group
Document for the M/490 Mandate
Smart Grids Reference Architecture

3534
3535
3536

124