OPEN-Meter WP2 D2.1 Part4 v1.0

Work Package: WP2/T2.1.3

Type of document: Deliverable Date: 19.06.2009

Energy Theme; Grant Agreement No 226369 Partners: CESI-R, DLMS, ENEL, KEMA, LANDIS&GYR, RWE

Responsible: CESI-R

Circulation: X Public

Confidential Restricted

Title: D2.1/4 State-of-the-art technologies & protocols Version: 1.0 Page: 1 / 72

OPEN meterOpen Public Extended Network meteringOPEN meterOpen Public Extended Network metering

D 2.1/PART 4

STATE-OF-THE-ART TECHNOLOGIES & PROTOCOLS -

DESCRIPTION OF STATE-OF-THE-ART COMMUNICATION PROTOCOLS AND DATA STRUCTURES

DUE DELIVERY DATE: 30.03.2009

ACTUAL DELIVERY DATE: 19.06.2009

© Copyright 2009 The OPEN meter Consortium

Project Funded by the European Commission under the 7th Framework Programme Project coordinated by


Type of document: Deliverable

Date: 19.06.2009

Energy Theme; Grant Agreement No 226369 Title: State-of-the-art technologies & protocols Version:1.0 Page: 2 / 72



Document History

Vers. Issue Date Content and changes

0.1 12.03.09 ToC

0.2 17.03.09. comments from the DLMS UA / RWE / KEMA 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0

18.03.09 23.03.2009 23.03.2009 30.03.2009 31.03.2009 20.04.2009 22.04.2009 19.06.2009

revised ToC revised ToC (application / network layer) overview table first inputs draft completed final inputs and comments from partners inputs from ENDESA, Actaris Final document (with comments from TC)

Document Authors

Partners Contributors

CESI RICERCA Giuseppe Mauri, Diana Moneta

DLMS UA Gyozo Kmethy

ENEL Giuseppe Fantini

KEMA Willem Strabbing, Wolf Freudenberg

LANDIS & GYR Heinz Hohl, Thomas Schaub

RWE Timm Gerbaulet, Hans-Werner Kneitinger, Thomas Wiedemann, Gerhard Radtke

ACTARIS Frederic Tarruell

ENDESA José Comabella

Document Approvers

Partners Approvers

CTI Markus BITTNER



Date: 19.06.2009




DLMS UA Gyozo Kmethy

KEMA Willem Strabbing, Wolf Freudenberg

RWE Timm Gerbaulet



Date: 19.06.2009




TABLE OF CONTENTS

1 PURPOSE 12 2 INTRODUCTION 13 3 KEY CHARACTERISTICS OF AMR 15 4 KEY CARACTERISTICS FOR AMI AND HOME AUTOMATION 15

4.1 GATEWAY BETWEEN AMI AND HOME AUTOMATION SYSTEM 16 4.2 DER CONTROL 17

5 TECHNOLOGIES OVERVIEW 17 6 COMMUNICATION PROTOCOLS AND DATA STRUCTURES 19

6.1 IEC 61334 S-FSK PLC 19 6.1.1 Introduction 19 6.1.2 Status of standardization 19 6.1.3 Support organization 20 6.1.4 Conformance testing and product certification 20 6.1.5 Field of application 20 6.1.6 Summary of technical features 21 6.1.7 Summary 22

6.2 IEC 62056-21 “FLAG” 22 6.2.1 Introduction 22 6.2.2 Status of standardization 23 6.2.3 Support organization 23 6.2.4 Conformance testing and product certification 23 6.2.5 Field of application 23 6.2.6 Summary of technical features 24 6.2.7 Summary 24

6.3 IEC 62056-31 EURIDIS 24 6.3.1 Introduction 24 6.3.2 Status of standardization 25 6.3.3 Support organization 25 6.3.4 Conformance testing and product certification 25 6.3.5 Field of application 25 6.3.6 Overview of technical features 26 6.3.7 Summary 26

6.4 DLMS/COSEM: IEC 62056, EN 13757-1 26 6.4.1 Introduction 26 6.4.2 Status of standardization 28 6.4.3 Support organization 29 6.4.4 Conformance testing and product certification 30 6.4.5 Field of application 30 6.4.6 Overview of technical features 31 6.4.7 Summary 37

6.5 M-BUS: EN 13757 38 6.5.1 Introduction 38 6.5.2 Status of standardization 38 6.5.3 Support organization 39 6.5.4 Conformance testing and product certification 40



Date: 19.06.2009




6.5.5 Field of application 40 6.5.6 Summary of technical features 40 6.5.7 Summary 44

6.6 SMART MESSAGE LANGUAGE (SML) 44 6.6.1 Introduction 44 6.6.2 Status of standardisation 46 6.6.3 Support organization 46 6.6.4 Conformance testing and product certification 47 6.6.5 Field of application 47 6.6.6 Data model 47 6.6.7 Communication media supported 49 6.6.8 Summary 50

6.7 IP TELEMATRIC PROTOCOL E-DIN 43863-4 51 6.7.1 Introduction 51 6.7.2 Status of standardisation 51 6.7.3 Support organization 51 6.7.4 Conformance testing and product certification 51 6.7.5 Field of application 52 6.7.6 Data model 52 6.7.7 Communication media supported 53 6.7.8 Summary 53

6.8 IEC 60870-5 54 6.8.1 Introduction 54 6.8.2 Status of standardisation 55 6.8.3 Support organization 55 6.8.4 Conformance testing and product certification 55 6.8.5 Field of application 55 6.8.6 Data model 55 6.8.7 Communication media supported 55 6.8.8 Summary 56

6.9 IEC 61968-9 56 6.9.1 Introduction 56 6.9.2 Status of standardization 57

6.10 SITRED 57 6.10.1 Introduction 57 6.10.2 Protocol Layers 58

6.11 PRIME 58 6.12 IEC 61850 59

6.12.1 Data Information 59 6.12.2 Logical nodes for the DER plant ECP logical device 60

6.13 KNX 62 6.14 ZIGBEE SMARTENERGYPROFILE 63 6.15 6LOWPAN 64 6.16 HOMEPLUG 65 6.17 Z-WAVE 65 6.18 WAVENIS 66 6.19 EVERBLU 66

6.19.1 Introduction 66 6.19.2 Status of standardization 66



Date: 19.06.2009




6.19.3 Field of application 66 6.19.4 Summary of technical features 67

6.20 OPERA/UPA 68 6.21 ITU-G.HN 68

6.21.1 G.hn Overview 68 6.21.2 G.hn security 69 6.21.3 G.hn Layered reference model 70 6.21.4 G.hn industry support 71

7 CONCLUSIONS ERROR! BOOKMARK NOT DEFINED.

8 COPYRIGHT ERROR! BOOKMARK NOT DEFINED.

LIST OF TABLES TUTab. 1 – IEC 62056-31 protocol stacksUT ................................................................................................................. 26

LIST OF FIGURES TUFig. 1 – General architectureUT................................................................................................................................. 13 TUFig. 2 – The three step approach of DLMS/COSEM UT ............................................................................................. 27 TUFig. 3 – COSEM interface objects UT ......................................................................................................................... 32 TUFig. 4 – DLMS/COSEM communication profiles – examples UT ................................................................................ 36 TUFig. 5 – SML communication model UT ...................................................................................................................... 46 TUFig. 6 –SML messages and communication paths UT................................................................................................ 49 TUFig. 7 – DIN 86436-4 data model UT .......................................................................................................................... 52 TUFig. 8 – PRIME architectureUT .................................................................................................................................. 59 TUFig. 9 – IEC 61850 Information model hierarchy UT ................................................................................................... 60 TUFig. 10 – Example of ECP for DERsUT ..................................................................................................................... 61 TUFig. 11 – ZigBee layersUT ......................................................................................................................................... 64 TUFig. 12 – EverBlu architectureUT ...............................................................................................................................67 TUFig. 13 – G.hn layered model UT ................................................................................................................................ 70



Date: 19.06.2009




GLOSSARY AND ACRONYMS OPEN meter Open Public Extended Network metering AMR Automatic meter reading technologies include handheld, mobile and

network technologies based on telephony platforms (wired and wireless), radio frequency (RF), or power line transmission

AMI Advanced Metering Infrastructure refers to systems that measure, collect and analyse energy usage, from advanced devices such as electricity meters, gas meters, and/or water meters, through various communication media on request or on a pre-defined schedule. Solutions include a wide range of applications in the field of remote meter reading, customer relationship management, demand-side management and value added services.

3G telephony 3rd Generation telephony AA Application Association ACSE Association Control Service Element AE Application Entity AES Advanced Encryption Standard AP Application Process ASE Application Service Element BOM Bill of Material CAS Central Access Server CEER Council of European Energy Regulators CEN Comité Européen de Normalisation CENELEC European Committee for Electrotechnical Standardization CIASE Configuration Initiation ASE (S-FSK PLC) COSEM Companion Specification for Energy Metering CTT Conformance Test Tool (DLMS/COSEM) DC Data Concentrator DER Distributed Energy Resources DLC Distribution Line Carrier (same as PLC) DLMS Distribution Line Message Specification (IEC 61334-4-41) – Device

Language Message Specification (IEC 62056) DSM Demand Side Management ESCO Energy Service Company EU European Union EURELECTRIC The association of the electricity industry in Europe GCM Galois/Counter Mode (cryptography) GO Grid Operator GPRS General Packet Radio Service GSM Global System for Mobile communications GSM/GPRS Global System for Mobile communications/General Packet Radio Service HA Home Automation HEMS Home & Building Management System HVAC Heating, ventilating, and air conditioning



Date: 19.06.2009




IC Interface class (COSEM) IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronic Engineers IP Internet Protocol ISP Independent Service Provider LD Logical Device (COSEM) LLC Logical Link Control LV Low Voltage MAC Medium Access Control MIB Management Information Base M&S Metering & Switching equipment MV Medium Voltage OBIS Object Identification System OFDM Orthogonal Frequency Division Multiplex OSI Open Systems Interconnection PDU Protocol Data Unit PHY Physical layer PLC Power Line Carrier / Power Line Communication PSTN Public Switched Telephone Network SDU Service Data Unit S-FSK Spread Frequency Shift Keying TCP Transmission Control Protocol TCP/IP Transport Control Protocol / Internet Protocol



Date: 19.06.2009




Name Description Abbrev.

Measuring and switching equipment

All equipment installed at the premises of the consumer for measuring consumption of commodities or for (dis)connecting the consumer. The equipment therefore includes: E meter, E-breaker, G meter, G-valve (the same for heat and water) and a communications module.

M&S equipment

Metering equipment

Equipment with measurement functions for electricity, gas, heat, and water. The equipment therefore includes E meters, G meters, H meters, and W meters.

Communication equipment

All equipment installed at a network hub. Primary function is to facilitate communication with M&S equipment over the network and with central systems over the telecom network. Secondary function is to provide functionality for optimisation of data transfer. The equipment is implemented in a Data Concentrator that therefore includes a communication module. The communication module can be either modular component or integrated part of the Data Concentrator. Data concentrator is present if PLC or Wireless LAN is used. When GPRS is used, then metering equipment communicate directly with the CAS.

E-equipment All equipment installed at the premises of the consumer for measuring consumption of electricity or for (dis)connecting electricity. E-equipment therefore includes: E meter and E-breaker.

G-equipment All equipment installed at the premises of the consumer for measuring consumption of gas or for (dis)connecting gas. G-equipment therefore includes: G meter and G-valve.

H-equipment All equipment installed at the premises of the consumer for measuring consumption of heat or for (dis)connecting it. H-equipment therefore includes: H meter and H-valve.

W-equipment All equipment installed at the premises of the consumer for measuring consumption of water or for (dis)connecting it. W-equipment therefore includes: W meter and W-valve.

Data Concentrator

The implementation of Communication equipment installed at a network hub.

DC



Date: 19.06.2009





Meter Residential measuring device for either electricity, gas, heat, and water. Meters include E meter, G meter, H meter, and W meter.

E meter Residential measuring device for registration of electricity consumption and communication. The part of the E meter that handles communication, the communication module, can be either a modular component or an integrated part of the E meter.

G meter Residential measuring device for registration of gas consumption.

H meter Residential measuring device for registration of heat consumption.

W meter Residential measuring device for registration of water consumption.

Switch Switching device for either electricity or gas, heat and water. Switching devices for E are called (E-) breakers, switching devices for G are called (G-) valves.

E-connection The function location for E-equipment.

G-connection The function location for G-equipment.

H-connection The function location for H-equipment.

W-connection The function location for W-equipment.

Network hub The function location for DC equipment

Communication module

The equipment that is responsible for communication between M&S equipment at a connection and other entities (i.e. central systems or DC equipment).

Central access server

The equipment and software used by the GO to handle requests from Service Company’s and ISP’s with respect to metering installations. The CAS is also referred to as the central system.

CAS



Date: 19.06.2009





Equipment identifier

A global identifier for the equipment. The equipment identifier is composed of three parts: meter type, serial number and year of manufacturing. The equipment identifier should also include the identifier of the manufacturer. Equipment identifiers are represented as bar codes and also human readable codes.

Local host The equipment installed on a connection is composed of multiple pieces of equipment. This equipment is connected through a local network. The E meter functions as a local host for this network and is referred to as the local host in the context of its function as a network component.

Auxiliary equipment

Equipment provided by an Independent Service Provider or Energy Supplier that can be attached to the P1 port and can receive and process the information provided on P1, e.g. an in-house Energy Monitor. Also referenced as “Other Service Module” (OSM).

OSM

DC service area All meters in the distribution area serviced by the DC through a Power Line Carrier (PLC) network.



Date: 19.06.2009




1 PURPOSE The conventional functionality of Automatic Meter Reading (AMR) is changing in the direction of Smart multi-metering or multi-functional Advanced Metering Infrastructure (AMI) capable of creating value for energy consumers, network operators, metering operators and retailers. The future AMI supporting the electricity grid will have to include both distributed power generation and consumption, transporting not only electricity but also bi-directional data. This infrastructure includes hardware, software, communication channels, customer associated systems and meter data management software. This document lists communication protocols and data structures currently used for AMR and AMI solutions. In addition, further protocols, not specifically developed for AMR and AMI applications, will be described in short to highlight their possible application in this field.



Date: 19.06.2009




2 INTRODUCTION In order to have a good overview of the scope and the corresponding protocols used for AMR and AMI, Figure 1 presents the general architecture (interfaces), according to D1.1 scheme. Besides the fact to have an overview, it is important to clearly define the interfaces for both AMR and AMI.

Fig. 1 – General architecture

With reference to above figure, the following ports can be identified:

Port MI1 for the communication between the metering installation and the Data Concentrator (DC).

Port MI2 for the communication between the metering installation and the Central Access Server (CAS).

Port MI3 for communication with external devices (e.g. hand-held terminal) during installation and on-site maintenance of the metering installation.

Port MI4 for the communication between the metering system and one or more metering instruments and/or grid company equipments. The data models and protocols available for use on MI4 are described in chapter 6. The connection to the communication module or E–meter can be a bus system or a serial connection.

Port MI5 for the communication between the metering installation and ISP module or auxiliary equipment (a maximum amount of appliances can be connected). MI5 should



Date: 19.06.2009




be a bi-directional interface; it can be used for sending data to the metering system. An example for this port is a display and/or a switch. The data models and protocols available for use on MI5 are described in chapter 6. When a Data Concentrator is present, the interface is split to two sections: MI1 between the E-meter/communication module and the DC, and CI2 between the DC and the Central system. The data models and protocols available are described in chapter 6.

Port SI3 is the port on the CAS with which independent service providers, suppliers and grid companies gain access to the CAS. Note that SI3 is outside the scope of this document.

The roles assigned to this figure may have an impact of the protocols to be used. The roles are as follows: UService providersU

It is foreseen that ISP or suppliers will provide information to the customers based on the meter data – respecting the rules for privacy. The application for this can be various: offers for new contracts, energy savings and warnings regarding anomalous energy consumption. In the case of a pre-paid contract corresponding information such as the remaining credit can be displayed. A two way communication on this level is mandatory to allow intelligent functions regarding demand side management, distributed energy resources and energy savings. USupplier/Grid operator/Meter data responsible According to the European liberalised energy market, customers have a single company to deal with (“supplier” or “retailer”). The grid operator or the meter data responsible party is responsible for the installations of the metering equipment, but in this scenario they don’t interact directly with end-users. The module can communicate via the Grid using Power Line Carrier, or over the Internet, or finally on a public or dedicated wireless network (GPRS for example). Connection of all utility meters to the communication module shall be possible. For information of the energy end-user, a customer display unit is necessary, which may have additional functions. In addition to the electricity breaker / gas valve generally integrated to the E-meter and G-meter respectively, the control of external switches may be useful. The breaker/valve can be used to connect / disconnect the supply to the premises when: • the contract is opened / closed; • in a pre-payment mode, when the credit is exhausted; • when the consumption exceeds a pre-set limit. The limit may be a normal operational limit

or an emergency limit; • after a disconnection, re-connection may be performed by a remote command or

manually, if enabled.



Date: 19.06.2009




3 KEY CHARACTERISTICS OF AMR Part 1 provides a detailed analysis of functions to be offered by the Automated Meter Reading technologies. Here only main information are described. AMR technologies include handheld, mobile and network technologies based on telephony latforms (wired and wireless), radio frequency (RF), or power line carrier (PLC). The key characteristic of AMR is that data necessary for billing are collected in an automated way. This task can be performed: • locally using hand held terminals, via an optical port, a current loop or any other suitable

interface. The most widespread standard for this purpose is IEC 61107 / IEC 62056-21; • locally, with the meters connected to a local bus system. The two most widely used

standards for this are Euridis, IEC 62056-31 and M-Bus specified in the EN 13757 series. Euridis is widely used in France and M-Bus is widely used in Germany;

• remotely, using suitable media, like PSTN, GSM, GPRS, Power line carrier, the Internet, and radio mesh networks. These can be one way or two way.

The main Umeter functions U are: • measurement of energy consumption and demand. In the case of electricity meters, two

way energy flow – import / export – may be measured, to allow integrating local / distributed energy generation,

• load profiling; • power quality measurement; • load monitoring and load management: limitation, disconnect / reconnect; • event monitoring and logging, including tamper; • customer information, etc.

4 KEY CARACTERISTICS FOR AMI AND HOME AUTOMATION

Advanced Metering Infrastructure (AMI) refers to systems that measure, collect and analyse energy usage data, from advanced devices such as electricity meters, gas meters, heat meters, and/or water meters, through various communication media on request or on a pre-defined schedule. Remote meter reading and customer information are the core application. AMI solutions can also be used to support customer relationship management, demand-side management, as well as enable various value added services. When addressing the architecture of the AMI, a clear distinction has to be made between system architecture and protocol architecture: • The system architecture concerns the role of the E-meter as a gateway, the need (or not)

and the location of concentrators, the allocation of certain functions to the various system elements...etc. It may depend on factors like market organization, the communication



Date: 19.06.2009




technology selected, whether the smart system rollout is done by the network company the retailers or other entities, the business case drawn up for a certain project etc.

• The protocol architecture concerns the set of protocol layers selected and the way a lower layer supports the higher layers. Ideally, a common application data model (object model) and common higher protocol layers can be supported by various sets of lower layers, which are themselves dependent on the communication media selected.

AMM means Automated Meter Management systems, communication need to be two ways in order to provide advanced functionalities, like customers relation management, demand side management, local power quality monitoring etc. Several business processes could be considered: • customer management, including supplier change • energy supply / billing; • (pre)payment; • load management; • network condition and health monitoring; • meter condition and health monitoring; • outage management; • energy services. As a summary, the right system architecture depends on: - the market organization; - the media to be covered; - the communication media used.

4.1 Gateway between AMI and Home Automation System In several countries energy authorities are considering the opportunity to adapt their Demand Side Management (DSM) strategy to the new liberalised scenario involving LV customers. The customers’ ability to participate to the energy market will be substantially represented by the aptitude of modulating their own load profile as result of market signals (electricity price) or network signals (emergency). Generally, one refers to Demand Side Management (DSM) of the electric power meaning actions aimed to stimulate final users to modify their demand habits, in response to price signals and other relevant information, hopefully without decreasing the present level of the services offered. DSM requires exchanging information between utilities, meters and load control devices (when available at user side). Therefore, AMI could communicate not only with the distributor but also with customer with to some extent. The content of messages may range from energy prices and meter readings, to complex data structures and commands in case of users deploying advanced load control systems or, even, in the case of third party companies, like Energy Services Company (ESCO), responsible for energy management of user premises.



Date: 19.06.2009




Usual applications of Home & building management systems (BEMS) include security, blinds and lighting automation, HVAC, as separate systems. The Local Energy Management system combines signals received from retailer (tariffs) and user preferences regarding comfort and maintains maximum power flow with the network under a specified threshold (that may change every hour). Load and heating management could be proposed, i.e. the possibility of switching off/on some appliances when particular circumstances occur or decide whether if it is better to use electric or gas devices for HVAC purposes.

4.2 DER control The European Commission and national regulations are supporting a wide diffusion of Distributed Energy Resources (DER). In the future, ancillary services as frequency and voltage control, power balancing, restoration of supply could be requested to local generators. The electricity meter shall receive disconnection/reconnection order from the network operator system as well as disconnection/connection confirmation from external device through the data concentrator or through the meter. In future phases of the OPENmeter project these aspects will be evaluated. In the following, it is highlighted when a protocol supports DER control.

5 TECHNOLOGIES OVERVIEW This document is a state-of-the-art on Technologies and Protocols. The assessment process will be carried out in further deliverables of WP2.

Communication media that may be suitable for the purposes of AMR / AMI are the following:

• PSTN; • GSM/GPRS/UMTS (or other 2.5/3G technologies); • Powerline Communication (PLC); • Ethernet; • Wireless / radio mesh network. A detailed description of communication technologies is provided in deliverable D2.1 – part 2 and part 3. The following table summarizes main characteristics for each protocol.



Date: 19.06.2009




Ref

. pa

ra

6.1

6.2

6.3

6.4

6.5

6.6

6.7

6.8

6.9

6.10

6.11

6.12

6.13

6.14

6.15

6.16

6.17

6.18

6.19

6.20

6.21

Mes

h ra

dio

- - - - - Y - N

A

Y

Y Y

Y

Y - -

Wal

k by

ra

dio

- - - Y

Y

Y - N

A

- -

PLC

Y - - Y - Y - N

A

Y

Y Y Y Y

Y

Inte

rnet

- - - Y - Y

Y - N

A

Y Y

Y

GP

RS

- Y - Y - Y

Y - N

A

Y Y

Y - -

GS

M

- Y - Y - Y

Y - N

A

Y - -

PS

TN

Y Y

Y - N

A

- -

Com

mun

icat

ion

med

ia s

uppo

rted

Loca

l bu

s - Y

Y

Y

Y

Y - N

A

Y

Y - -

Dat

a m

odel

Y - - Y - Y

Y - N

A

- -

Hom

e au

tom

atio

n

- - - Y

Y

Y - N

A

- - Y

Y Y - - Y

AM

I

Y - - Y

Y

Y

Y - N

A

Y

Y Y Y

Y -

Rem

ote

AM

R

Y

Y

Y

Y

Y

Y

Y

Y

NA

Y

Y Y

Y -

Fiel

d of

app

licat

ion

Loca

l A

MR

- Y

Y

Y

Y

Y Y

NA

Y

Y Y - -

Spec

ifica

tion

IEC

613

34 P

LC

IEC

620

56-2

1”FL

AG

”

IEC

620

56-3

1 E

urid

is

IEC

620

56

DLM

S/C

OS

EM

EN

137

57 M

-Bus

SM

L

DIN

438

63-4

IEC

608

70-5

IEC

619

68-9

SIT

RE

D

PR

IME

I IE

C 6

1850

KN

X

Zigb

ee S

mar

tEne

rgy

6LoP

AN

Hom

eplu

g

Z-W

ave

Wav

enis

Eve

rBlu

OP

ER

A/U

PA

ITU

–G.h

n



Date: 19.06.2009




6 COMMUNICATION PROTOCOLS AND DATA STRUCTURES

For each protocol, the following information is provided (when available): • general description; • status of standardization, support organization, availability of conformance testing and

product certification; • field of application: Local AMR, Remote AMR, AMI, Home Automation; DER control only

whe supported; • summary of technical features: protocol stack, system architecture.

6.1 IEC 61334 S-FSK PLC For a detailed description of Narrow Band PLC technologies (NPL), please refer to part 2 – chapter 3. 6.1.1 Introduction The IEC 61334 S-FSK profile is part of the IEC 61334 standard suite, developed by IEC TC 57 WG09 at the end of the ’90-ies. It is a narrow band PLC technology working in the CENELEC A Band (EN 50065) and using spread frequency shift keying (S-FSK) modulation. Several meter and chip manufacturers are supporting it. The IEC 61334 standard suite also specifies the upper layers: an optional network layer, the Application layer and the DLMS application protocol. Recently, S-FSK PLC has been selected for the Dutch DSMR project. In these project, the lower layers (PHY + MAC + LLC) are used with the upper layers of DLMS/COSEM: the COSEM application layer and the COSEM data model to support smart metering / AMI functionality. This is the MI1 interface between the meters and the Data Concentrators (see §6.4.6.4). The French ERDF project also uses this profile.

6.1.2 Status of standardization The relevant standards are the following: IEC 61334-4-32 Ed. 1.0:1996, Distribution automation using distribution line carrier systems – Part 4: Data communication protocols – Section 32: Data link layer – Logical link control (LLC) IEC 61334-4-41 Ed.1.0:1996, Distribution automation using distribution line carrier systems – Part 4: Data communication protocols – Section 41: Application protocols – Distribution line message specification



Date: 19.06.2009




IEC 61334-4-42 Ed. 1.0: 1996, Distribution automation using distribution line carrier systems – Part 4: Data communication protocols – Section 42: Application protocols – Application layer IEC 61334-4-511 Ed. 1.0:2000, Distribution automation using distribution line carrier systems – Part 4-511: Data communication protocols – Systems management – CIASE protocol IEC 61334-4-512 Ed. 1.0:2001, Distribution automation using distribution line carrier systems – Part 4-512: Data communication protocols – System management using profile 61334-5-1 – Management Information Base (MIB) IEC 61334-5-1 Ed. 2.0:2001, Distribution automation using distribution line carrier systems – Part 5-1: Lower layer profiles – The spread frequency shift keying (S-FSK) profile These are open international standards.

6.1.3 Support organization The DLMS UA has extended the COSEM data model with the necessary interface classes / objects to support the S-FSK profile, and specified the new S-FSK PLC communication profile. These new elements are supported by the DLMS UA, and they will become part of the IEC 62056 standard suite. IEC TC 13 and IEC TC 57 will establish a co-operation on maintaining the IEC 61334 series.

6.1.4 Conformance testing and product certification Performance criteria are defined in “IEC 61334-5-1 Ed. 2.0:2001” – Distribution automation using distribution line carrier systems – Part 5-1: chapter 2.4 Performance Tests.

6.1.5 Field of application

6.1.5.1 Local AMR Not supported.

6.1.5.2 Remote AMR Supported.

6.1.5.3 AMI Supported when used with IEC 62056 DLMS/COSEM.

6.1.5.4 Home Automation Not supported.



Date: 19.06.2009




6.1.6 Summary of technical features In this document only main information are described. For further details, please refer to part 2 of this deliverable. 6.1.6.1 The protocol stack The S-FSK profile uses a collapsed OSI model: • the physical and MAC layers are specified in IEC 61334-5-1. It specifies the S-FSK

modulation scheme, and the services and protocols of the PHY and MAC layers. It also describes the repetition mechanism used to extend the action radius of the PLC signal. For details, please see §6.7.1 in part 2.

• the connection-less LLC layer specified in IEC 61334-4-32; • the IEC 61334-4-42 Application layer with the IEC 61334-4-41 DLMS Application

protocol; or • the IEC 62056-53 COSEM Application layer, with the IEC 62056-52 COSEM interface

classes and the IEC 62056-61 OBIS object identification system (used in the Dutch DSMR and the French ERDF projects);

• the CIASE protocol, IEC 61334-4-511 specifies how the concentrator (initiator) searches for meters and registers them. The CIASE protocol uses the services of the LLC layer. The DLMS UA has specified an intelligent initiator search mechanism and a Ping service to keep the meters “alive”. Revision of the standards will be initiated with IEC TC 57;

• the IEC 61334-4-512 MIB standard specifies management variables for the protocol layers. For the purposes of using the S-FSK PLC profile with DLMS/COSEM, these variables have been mapped to attributes and methods of S-FSK PLC setup COSEM objects.

6.1.6.2 System architecture An LV PLC system consists of one concentrator (also known as initiator) per MV/LV transformer and several meters along the distribution network supplied by that transformer. All communication is initiated by the concentrator. Meters can only access the medium when requested by the concentrator. Data from the concentrator may be stored and are forwarded to the meter management center via a suitable protocol. UExample: using web services between the concentrator and the Central Access Server In the Dutch DSMR specification, web services are used between the concentrator and the Central Access Server (CAS), the meter management system. This is specified as the CI2 interface. The salient points are the following. The CI2 interface is introduced because Data Concentrator (DC) can be placed between the Central Access System (CAS) and meters. DC divides the MI2-SI2 interface – from the meter to the CAS – into two parts: MI1-CI1 and CI2-SI1, where MI1 is based on DLMS/COSEM standard with S-FSK PLC and CI2 is based on Internet standards. The CI2 interface is based on Service Oriented Architecture (SOA) where standards are implemented with Web Services (SOAP) and XML.



Date: 19.06.2009




Web Services interoperability is achieved with compliance to WS-I Basic Profile 1.1 or WS-I Basic Profile 1.2. WS-I Basic profiles determine standards which can be used and the guidelines for using them. The following items are addressed: • Transport (HTTP and HTTPS); • Messaging (SOAP and XML); • Service Description (WSDL and XML Schema); • Service Publication and Discovery (UDDI); • Service Composition (WS-*); • Security (SSL/TLS-). CI2 interface uses WS-ResourceTransfer and WS-Eventing to model meter access resources with Web Services. Both Request/Response and Publish/Subscribe message exchange patterns are supported. Meter access resources enable access to COSEM objects in the meters; in other words, the web services know that the resources they are accessing are COSEM objects.

6.1.7 Summary S-FSK PLC provides reliable communication over power / distribution lines by combining frequency diversity, a robust repetition scheme and extensive error control. Combined with DLMS/COSEM it supports smart metering / AMI functionality. This profile has been selected by the Dutch DSMR project and the French ERDF project.

6.2 IEC 62056-21 “Flag”

6.2.1 Introduction IEC 62056-21 is the third edition of the well-known IEC 1107 standard, also known as the “Flag protocol”. Although it was intended for local data exchange using hand held units (HHU), it is also widely used for remote data exchange with PSTN and GSM modems. It specifies three local physical interfaces: optical, current loop and V.24 / V.28, as well as a data transmission protocol. The protocol permits reading and programming of devices, basically by reading and sending information represented by ASCII characters to / from given memory locations. The following communication modes are available: • Mode A supports bi-directional data exchange at 300 baud without baud rate switching.

This protocol mode permits data readout and programming with optional password protection;

• Mode B supports bi-directional data exchange with baud rate switching. This protocol mode permits data readout and programming with optional password protection;



Date: 19.06.2009




• Mode C supports bi-directional data exchange with baud rate switching and permits data readout, programming with enhanced security and manufacturer-specific modes;

• Mode D supports unidirectional data exchange at a fixed baud rate of 2400 baud and permits data readout only;

• Mode E supports advanced protocols, like DLMS/COSEM. The mode can be negotiated by the HHU and the meter. A meter can support more than one mode: today, support of Mode C and Mode E with DLMS/COSEM is common practice.

6.2.2 Status of standardization The current standard has been established by IEC 62056-21 WG 14: IEC 62056-21 Ed. 1.0:2002, Electricity metering – Data exchange for meter reading, tariff and load control – Part 21: Direct local data exchange (third edition of IEC 61107) The standard is open and widely used. However, the memory mapping is not standardized, therefore data exchange requires manufacturer specific information. Meters of different types or from different manufacturers are not readily interoperable: each meter type needs a specific driver. Annex C of the standard specifies formatted codes, but these are not widely used.

6.2.3 Support organization The mandatory three-letter manufacturer identifiers are allocated by the FLAG Association, in co-operation with the DLMS User Association. The same identifiers are also used for DLMS/COSEM. Some three hundred manufacturers have obtained their manufacturer ID. See at: HTUhttp://www.dlms.com/organization/flagmanufacturesids/index.html UTH

6.2.4 Conformance testing and product certification Not available.


6.2.5.1 Local AMR Supported, by using a hand held or a permanently connected device.

6.2.5.2 Remote AMR Supported via PSTN or GSM modems. Several devices can be connected on a current loop.

6.2.5.3 AMI Supported when used in Mode E with DLMS/COSEM and remote two-way communication.




Date: 19.06.2009




6.2.6 Summary of technical features

6.2.6.1 Data model Not available in modes A to D, data are located and manufacturer specific memory addresses.

In Mode E, the COSEM data model and protocol stacks are used.

6.2.6.2 Communication media supported The current loop is a local bus supporting up to eight meters. PSTN and GSM are supported with appropriate modems.

6.2.7 Summary This protocol was the first standard protocol for meter data exchange and is globally used. Today, its main use is for local data exchange.

6.3 IEC 62056-31 Euridis Source: HTUhttp://www.euridis.org/UTH and the relevant standards and drafts.

6.3.1 Introduction Euridis is a pragmatic and reliable solution for remote meter reading. Introduced at the beginning of the 1990's, the protocol has been standardised by IEC TC13 WG 14. The standard has been evolved from IEC 61142 to the actual IEC 62056-31. Nowadays, Euridis is the only standardised interface for the remote reading of electricity meters with a twisted-pair cable, using carrier signalling. Euridis: • permits to read, write in all security and reliability; • is a low cost solution; • works with 100 meters between access points; • is easy to read for customers and utilities; • presents guarantee and openness of international standard (IEC 62056-31). UMain functions: • remote reading of registers; • remote programming; • alarm call back and reset; • energy remote supply (water, gas, heating, ...); • automatic detection of equipment. USecurity: • magnetic plug to prevent access;



Date: 19.06.2009




• securised data. USimplicity: U

• single twisted pair; • no connecting and topology bus constraints. UPerformance: U

• up to 500 meters local bus; • 3 minutes to read 100 meters; • baud rate: 1 200 Baud.

6.3.2 Status of standardization The current standard has been established by IEC TC 13 WG 14:

IEC 62056-31 Ed. 1.0:1999 Electricity metering – Data exchange for meter reading, tariff and load control – Part 31: Using local area networks on twisted pair with carrier signalling Beginning of 2009, an evolution has been proposed for international standardization: • to increase speed from 1 200 to 9 600 Baud; • to support DLMS/COSEM. IEC 62056-31 is an open standard.

6.3.3 Support organization The Euridis specification is supported by the Euridis Association: HTUhttp://www.euridis.org/ UTH. It has some 30 members.

6.3.4 Conformance testing and product certification A conformance test specification is available at:

HTUhttp://www.euridis.org/pdf/commitee/DossierDeTests_Ed05_GB.pdf UTH

The list of certified meters is not available.


6.3.5.1 Local AMR Supported, by using a hand held or a permanently connected device, via a magnetic plug. Gateways to other protocols are possible.

6.3.5.2 Remote AMR Euridis is a pragmatic and reliable solution for remote meter reading.



Date: 19.06.2009




6.3.5.3 AMI Not supported.


6.3.6 Overview of technical features

6.3.6.1 Data model Euridis does not specify a data model. With the new evolution, DLMS/COSEM will be supported.

6.3.6.2 Communication media supported Euridis supports twisted pair local bus with carrier signalling. The standard uses a collapsed OSI model, as shown in Tab. 1.

Tab. 1 – IEC 62056-31 protocol stacks

Without DLMS With DLMS

With DLMS/COSEM

(future)

Physical layer clause 3.1 clause 3.1 clause 3.1

Link layer clause 3.2 clause 4.2 Link-E/D clause 4.2 Link-E/D

Application layer clause 3.3 IEC 62056-51 IEC 62056-53

6.3.7 Summary IEC 62056-31 Euridis is a protocol for local bus using twisted pair with carrier signalling. It is widely used in France – with more than 10 million meters installed – in some Francophone countries and some other countries. A revision of the standard has been initiated to adapt it to new needs: • higher speed; • use with DLMS/COSEM.

6.4 DLMS/COSEM: IEC 62056, EN 13757-1 6.4.1 Introduction DLMS/COSEM is an open international standard for data exchange with utility meters measuring any kind of energy, more generally, with intelligent devices. It has been developed at the end of the 1990’s by leading utilities and meter manufacturers with the objective to provide a means for meter data exchange in a standard, interoperable, energy type and manufacturer independent way, over a range of communication media. To meet



Date: 19.06.2009




these objectives, DLMS/COSEM uses a three-step approach, illustrated in the following figure.

3. Transporting

C0 01 00 03 01 01 01 08 00 FF 02

2. Messaging

Protocol Services to access attributes and methods

ISO, IEC,...

Communication Protocol

Messages :Service_Id( Class_Id, Instance_Id, Attribute_Id/Method_Id )

Encoding: ( APDU )

1. Modelling COSEM Interface Objects

Register 0..n Class_id=3, Version=0Attribute(s) Data Type Min Max Def1. logical_name (static) octet-string2. value (dyn.) instance specific3. scaler-unit (static) scal_unit_typeMethod(s) m/o1. reset o

DLMS User A

ssociation

Fig. 2 – The three step approach of DLMS/COSEM

UStep 1, Application data modelling:U this encompasses the COSEM interface object model and the OBIS data identification system; see 6.4.6.1 and 6.4.6.2.

UStep 2, Messaging:U this encompasses services for using the data model. These are the DLMS services provided by the COSEM application layer; see 6.4.6.3.2.

UStep 3, Transporting:U this encompasses communication profiles, i.e. the rules for transporting the APDUs through various communication channels; see 6.4.6.4. Key features of DLMS/COSEM:



Date: 19.06.2009




• communication and messaging method independent data model and identification system: the COSEM interface objects, identified with OBIS codes, model the application independently of the messaging method and the communication method;

• multi-energy: all energy types – electricity, gas, water and heat etc. – are covered. The interface classes are the same, only their OBIS codes are media / energy type specific;

• self-description: the meter provides information on the resources – the list of objects – available. The meter also provides in each message the data type used. Consequently, the data collection system and the meter can exchange data based solely on the information taken from the standard and read from the meter, with minimum reliance on information coming from the manufacturer, like passwords, secrets, any manufacturing specific elements. This facilitates plug-and-play;

• DLMS messaging services common for all ICs / objects: these are used to access the attributes and methods of COSEM objects. This means that new interface classes can be specified to cover new functions, without affecting the protocols. For encoding, the efficient IEC 61334-6 A-XDR standard is used;

• client-server approach: the meters act as servers, providing the requested data / services to the meter management system, acting as a client. The meters can also send unsolicited information: alarms, pre-defined data sets (push operation);

• role based access: the server can provide a different scope of access to different clients playing different roles: end user, meter reader, utility engineer, manufacturer...

• OSI/Internet based protocol stacks carrying the messages. Any communication media, capable of carrying DLMS APDUs is suitable. The communication media currently supported are the following: local optical/electrical ports, PSTN, GSM, Internet, GPRS, PLC, M Bus, Euridis...

• separation of the data model and the protocols – “orthogonality”: the data model and the protocols are neatly separated. The interface between them is provided by the DLMS messaging services. This means that the object model can be developed without affecting the protocols and the protocols can be developed without affecting the model. This renders the specification to be future proof;

• alternative messaging methods, like XML are possible and are under consideration; • negotiation of capabilities: the client and the server can negotiate features and

capabilities at all protocol layer levels and at the model level, to be used during the data exchange. This facilitates interoperability;

• flexibility and scalability: there are only a few mandatory elements in DLMS/COSEM which must be implemented. This allows building both simple and complex meters and thereby to optimize costs;

• data transport security: application layer level data transport security is available by using the AES-GCM-128 symmetric key algorithm, providing authenticated encryption.

6.4.2 Status of standardization DLMS/COSEM is internationally standardized by IEC TC 13 for electricity metering and by CEN TC 294 for metering other utilities than electricity. The relevant standards are the following:



Date: 19.06.2009




IEC 61334-4-41 Ed.1.0:1996, Distribution automation using distribution line carrier systems – Part 4: Data communication protocols – Section 41: Application protocols – Distribution line message specification IEC 62056-46 Ed. 1.1:2007 Electricity metering – Data exchange for meter reading, tariff and load control – Part 46: Data link layer using HDLC protocol IEC 62056-47 Ed. 1.0:2006 Electricity metering – Data exchange for meter reading, tariff and load control – Part 47: COSEM transport layers for IPv4 networks IEC 62056-53 Ed. 2.0:2006 Electricity metering – Data exchange for meter reading, tariff and load control – Part 53: COSEM Application layer IEC 62056-61 Ed. 2.0:2006 Electricity metering – Data exchange for meter reading, tariff and load control – Part 61: Object identification system (OBIS) IEC 62056-62 Ed. 2.0:2006 Electricity metering – Data exchange for meter reading, tariff and load control – Part 62: Interface classes EN 13757-1:2002, Communication system for meters and remote reading of meters – Part 1: Data exchange The most up-to-date version of the specification is available in the “Coloured books” issued by the DLMS UA. These books are available for all members free of charge: DLMS UA 1000-1 Ed. 9.0:2009, “Blue Book” COSEM Identification System and Interface Classes DLMS UA 1000-2: Ed.6.0:2007, “Green Book” DLMS/COSEM Architecture and Protocols (Edition 7.0 is in preparation) DLMS UA 1001-1 Ed. 3.0:2007, ‘Yellow Book”, DLMS/COSEM Conformance testing process. The revision of the IEC 62056 standards has been initiated to transfer the new elements to international standardisation. The IEC 62056 / EN 13757–1 DLMS/COSEM standards are open international standards.

6.4.3 Support organization DLMS/COSEM is supported by the DLMS User Association, having some 130 members from some 50 countries. Membership is open to any person or organization active in meter



Date: 19.06.2009




data exchange. The membership fee is nominal. The DLMS UA maintains an official liaison with IEC TC 13 WG 14, acting as a registration authority and a maintenance agency. The DLMS UA provides the following services: • registration of standard elements, like OBIS codes, interface class Ids; • maintenance and development of the specification by the working groups, open to all

members; • specification of conformance testing; • product certification; • user support. For more, see: HThttp://www.dlms.com/index2.php TH

6.4.4 Conformance testing and product certification The DLMS UA has developed conformance test plans and provides a Conformance Test Tool, accessible to any members under fair and equal conditions. Both self-testing and third party testing is available. Certificates are issued by the DLMS UA. To date, 100+ meters types have been certified. See at: HThttp://www.dlms.com/conformance/listofcompliantequipment/index.html TH


6.4.5.1 AMR with local data exchange DLMS/COSEM supports local data exchange for AMR via an optical port, current loop interface or RS-232. The physical interfaces are specified in IEC 62056-21. Most meters on the market support both Mode C using ASCII data transfer and Mode E using DLMS/COSEM.

6.4.5.2 AMR with remote data exchange DLMS/COSEM is widely used for AMR with two-way remote data exchange over various media.

6.4.5.3 AMI The functions modelled with the COSEM data model support all AMI functionality; see in 6.4.6. Combined with bi-directional data exchange, DLMS/COSEM supports AMI, and it has been selected, among others, as a basis of the Dutch and the French projects.

6.4.5.4 Home automation Home automation is currently not supported by DLMS/COSEM. However, DLMS/COSEM devices may serve as a gateway towards HA systems. The principles of the COSEM model also make it suitable to model HA functionality.



Date: 19.06.2009




6.4.6 Overview of technical features

6.4.6.1 The COSEM data model The COSEM data model presents the functionality of the meter at its interfaces. It specifies a library of COSEM interface classes (IC) and the OBIS Object Identification System. The functional requirements are mapped to COSEM objects delivering those functions. Each and every object is identified by its OBIS code. The COSEM model is independent of the communication media, so that the required functionality can be provided the same way over any media. Meters for any utilities – like electricity, gas, water, and heat – for any application segment, and of any complexity can be modelled and built. Using the COSEM model fosters a common understanding of the metering tasks among the various manufacturers, while leaving freedom in implementation and leaving scope for innovation. A COSEM Interface Class (IC) is characterized by a set of attributes and methods, which serve to describe some externally visible features of the class. Each attribute has a defined meaning; the first attribute (of each COSEM IC) is called the logical name. An attribute can be static, to hold configuration data, or dynamic, updated by the metering process. Each method defines a certain operation on one or more attributes. Attributes may be read or written and methods can be invoked remotely via the communication interface(s) or locally by the metering Application Process (AP). A COSEM IC may have several instances, called COSEM objects, identified with an OBIS code. The COSEM ICs are shown in the following scheme. The interface class Association controls a role-based access to the resources of the meter. The interface class Profile generic has a special importance: it allows packing any data set in single, self-descriptive objects, the contents of which can be retrieved with a single command.



Date: 19.06.2009




Base

Dataclass_id: 1

Association SNclass_id: 12

Clockclass_id: 8

IEC local portsetup

class_id: 19

Registerclass_id: 3

Extended registerclass_id: 4

Demand registerclass_id: 5

Register tableclass_id: 61

Profile genericclass_id: 7

Status mappingclass_id: 63

Association LNclass_id: 15

SAP Assignmentclass_id: 17

Script tableclass_id: 9

Scheduleclass_id: 10

Utility tablesclass_id: 26

Special daystable

class_id: 11

Activity calendarclass_id: 20

Registeractivationclass_id: 6

IEC HDLC setupclass_id: 23

Register monitorclass_id: 21

Single actionschedule

class_id: 22

Modemconfigurationclass_id: 27

Auto answerclass_id: 28

Auto connectclass_id: 29

IEC twisted pair(1) setup

class_id: 24

TCP-UDP setupclass_id: 41

IPv4 setupclass_id: 42

Ethernet setupclass_id: 43

M-Bus slaveport setup

class_id: 25

PPP setupclass_id: 44

GPRS modemsetup

class_id: 45

SMTP setupclass_id: 46

Data storage Access controland management

Time- and eventbound control Communication channel setup

S-FSK PHY&MACsetup

class_id: 50

S-FSK Activeinitiator

class_id: 51

S-FSK MACsync timeoutsclass_id: 52

S-FSK IEC 61334-4-32 LLC setup

class_id: 55

S-FSK Reportingsystem listclass_id: 56

IEC 8802-2 LLCType 1 setupclass_id: 57



S-FSK MACcounters

class_id: 53

Security setupclass_id: 64

Disconnectcontrol

class_id: 70

Limiterclass_id: 71

M-Bus clientclass_id: 72

Image transferclass_id: 18

M-Bus masterport setup

class_id: 74

Wireless Mode Qchannel setupclass_id: 73

Fig. 3 – COSEM interface objects

The COSEM interface classes allow modelling the various metering applications and functions of the meter like: • energy and demand metering; • measurement of instantaneous values; • value monitoring; • power quality measurement; • gas volume conversion, gas quality measurement; • time of use; • scheduled activities; • load profiles; • event logging; • load management; • setting up the communication channels. A number of new interface classes and new object instances have been specified and added to the specification: • connection / disconnection of supply to the premises (electricity breaker, gas valve); • firmware update; • security setup;



Date: 19.06.2009




• S-FSK PLC channel setup; • customer information; • event / alarm handling; • data exchange with M-Bus meters.

6.4.6.2 The OBIS Object identification system

OBIS is a naming system, based on the German EDIS standard T

1T, which has been

developed also in the 1990’s. Its original purpose was to identify data on the meter display in a standard and unambiguous way. OBIS builds on EDIS and it is upper compatible with it. It is used to identify interface objects as well as data elements on the display. OBIS is a hierarchical system, consisting of six value groups A to F. In general, each lower-level value group provides a classification for the quantities identified by upper-level value groups: • Value group A (the highest level in the hierarchy) identifies the energy type (media) to be

measured. The value A = 0 identifies “abstract”, media or energy-type independent objects, common for all kind of meters;

• Value group B classifies the quantities identified by value group A; its typical use is to identify measurement channels;

• Value group C further classifies the quantities identified by value group A to B. Its typical uses are to identify physical quantities, like voltage, current, active / reactive / apparent power, pressure, volume, flow or abstract data items;

• Value group D further classifies the quantities identified by value group A to C. The meaning of each value depends on the values A to C. Its typical use is to identify the way a physical quantity is processed for example averaged, integrated, monitored;

• Value group E further classifies the quantities identified by value group A to D. The meaning of each value depends on the values A to D; its typical use is to identify tariff rates;

• Value group F further classifies the quantities identified by value group A to E; its typical use is to identify historical values.

The range in each value group is 0 to 255. In some value groups, manufacturer-, country- or consortia-specific ranges are available. Standard OBIS codes are allocated by the DLMS UA. A document called “Object definition tables”, listing all defined combinations of the values in the six value groups, together with the interface class(es) and data type(s) to be used is maintained by the DLMS UA and it is available at HThttp://dlms.com/members/List-OBIS.htmTH. It is used by the CTT for conformance testing of the COSEM interface objects.

T

1T EDIS: Energy Data Identification System, DIN 43863-3



Date: 19.06.2009




6.4.6.3 Messaging

6.4.6.3.1 Introduction To exchange data with meters using the COSEM interface model, the information modelled has to be turned into a form, which can be transported via communication channels. Currently only one messaging method is specified, DLMS. Alternative messaging methods – for example XML – are possible and they are under consideration.

6.4.6.3.2 DLMS services DLMS specifies services and protocols to build messages – carrying the information modelled and held by the COSEM objects – that are transported over various communication media. It is designed so, that the object model can be extended as required to cover new applications, without affecting the messaging system. The original DLMS standard, IEC 61334-4-41, has been developed by IEC TC 57, as part of the IEC 61334 standard suite for distribution automation using distribution line carrier systems T

2T. On the one hand, DLMS/COSEM uses only a part of the DLMS standard and

therefore it is much simpler. On the other hand, it adds a few extensions for an efficient use of the COSEM model. This extended DLMS constitutes the xDLMS ASE of the COSEM application layer. It is important to note, that DLMS as specified in IEC 61334-4-41 does not provide a meter data model or a naming system. Adding these elements is one of the main evolutions brought by DLMS/COSEM. DLMS/COSEM uses a client/server concept. The data collection system acts as a client, requesting services. The logical devices of the meter act as servers, responding to service requests. NOTE The metering functionality needed for a particular metering site may be provided by a single physical device or may be distributed across several physical devices, e.g. a metering unit, a tariff- or load control unit, a house gateway and a customer interface unit.

For accessing attributes and methods of COSEM objects, their attributes and methods have to be referenced. There are two possibilities available: • Logical Name (LN) referencing: the attributes and methods are referenced with the triplet

{class_id, logical_name, attribute/method id}. The services are GET, SET ACTION and EventNotification;

• Short Name (SN) referencing: each attribute and methods is mapped to a DLMS named variable. The services are Read, Write, UnconfirmedWrite and InformationReport. The mapping is provided by the meter for the client, to obviate the need for manufacturer specific information.

T

2T The original meaning of DLMS is Distribution Line Message Specification. To reflect the extended scope of

application, DLMS stands now for Device Language Message Specification.



Date: 19.06.2009




The referencing method is negotiable upon Association establishment. A meter may support both LN and SN referencing. Clients should support both LN and SN referencing to work with any meter in an interoperable way. With this, full interoperability is maintained between the two approaches.

6.4.6.4 Communication profiles DLMS/COSEM specifies a number of communication profiles for various communication media: • the 3 layer, HDLC (ISO/IEC 13239) based, connection oriented (CO) profile. It supports

data exchange over the local ports: optical, current loop, or RS 232 as well as via PSTN and GSM;

• the TCP/IP based communication profile. It supports data exchange over the Internet, GPRS;

• the S-FSK PLC profile (with lower layer as specified in IEC 61334 5-1 and 4-32); • M-Bus – EN 13757 (with appropriate CI values); • Euridis – IEC 62056-31.

Examples of DLMS/COSEM communication profiles are shown in the following figure. The 3-layer, connection-oriented, HDLC based and the TCP/IP based profiles profile are widely used in the commercial / industrial segment with over PSTN/GSM modems. The TCP/IP based profile with GPRS is also used in smart metering project. In the Dutch DSMR project, this is the MI2 interface between the meters and the Central Access Server (CAS). The S-FSK PLC profile is the CI1 interface between the meters and the concentrator. It has been also selected for the ERDF project. NOTE In the Dutch Project, on the CI2 interface between the concentrator and the CAS, web-services are used. In any DLMS/COSEM communication profile, the top layer is the COSEM Application layer. Any set of lower layer can be used, which can transport COSEM APDUs. DLMS/COSEM can be used over any communication media, capable to support the COSEM Application layer. For any new communication media, the following elements have to be specified: • addressing of Application Processes / Logical Devices by the supporting layers of the

COSEM Application layer; • establishment and release of Application Associations; • the use of confirmed and unconfirmed Associations, confirmed and Unconfirmed DLMS

services.



Date: 19.06.2009




COSEM data model

COSEM Application layerACSE xDLMS Security

ASE

LLCIEC 61334-4-32

Sup

p. la

yer

HDLC

Phy layer

TCP

App

l. la

yer

IPv4

Supportinglayers

AL

3-layer,CO HDLC TCP-UDP/IP

IEC 61334-5S-FSK PLC

profile

App

l. la

yer

MAC +PhyIEC 61334-5-1

S-FSK

Wrapper

Connectionmanager

Sup

p. la

yer

Fig. 4 – DLMS/COSEM communication profiles – examples

6.4.6.5 Data security Data security comprises access security, and data transport security. Access security is controlled by Association objects. For data transport security, DLMS/COSEM has selected the AES-GCM-128 symmetric key algorithm, providing authenticated encryption. This algorithm is believed to provide sufficient protection until 2030 and beyond.

6.4.6.6 The role of companion specification To cover the largest possible range of applications, international standards specify a wide range of possibilities and options. They can be seen as a set of standard building blocks, of



Date: 19.06.2009




which tailor-made applications can be built. On the other hand, they specify only those elements, on which an international consensus can be reached. While the internationals standard has all the indispensable elements that are necessary to build interoperable systems, companion specifications are useful to facilitate achieving interoperability. Such companion specifications are generally project specific, and, among others, specify the following elements: • the list of features, elements and functions, which are not mandatory by the international

standard, but are necessary to support the required functions; • the choices to be taken where the international standard offers alternatives; • fixing some parameters; • the elements, where the international standard leaves freedom for project specific

solutions; • handling of any manufacturer specific elements; • the flexibility or “intelligence” required on the data collection system side, to be able to

work together with meters from various manufacturers. It is essential that this companion standard be developed by a joint effort of manufacturers and utilities and other stakeholders. The Dutch DSMR specification is a good example for a companion standard to DLMS/COSEM.

6.4.7 Summary DLMS/COSEM is a modern specification, specifying the COSEM data model, the OBIS identification system, the DLMS messaging services and communication profiles / protocol suites for a range of communication media. It supports all applications: local and remote two-way data exchange, AMR and AMI. Its flexibility makes it suitable for simple and complex systems. Interoperability is supported by its self-descriptive properties, capability- and context negotiation. It uses efficient data organization tools, efficient encoding and advanced access and message security features. Recently, it has been successfully extended to support smart metering / AMI requirements, and its built-in standard extension mechanisms ensure that it can cope with future requirements. With this, it is well positioned as a core standard for smart metering / AMI.



Date: 19.06.2009




6.5 M-Bus: EN 13757

6.5.1 Introduction M-Bus “Meter bus” is a European standard, used mainly for one-way or two-way data exchange with utility meters. Today, it is mainly used with heat, gas and water meters. It can also be used with various sensors and actuators. It is standardised by CEN TC 294, "Communication systems for meters and remote reading of meters" in the EN 13757 series. TC 294 covers data exchange with all utility meters except electricity meters, which are covered by IEC / CENELEC TC 13. EN 13757-1 is a general standard for meter data exchange, covering several physical media, protocols and the COSEM application data model. The parts EN 13757-2...EN 13757-6 specify the M-Bus protocol layers. M-Bus uses an OSI three-layer (collapsed) protocol architecture, consisting of: • the wired or the wireless physical layer; • the data link layer based on IEC 60870-5-1 and IEC 60870-5-2; • the (M-Bus) dedicated application layer. M-Bus can alternatively be used with DLMS/COSEM: the COSEM Application layer specified in IEC 62056-53, the COSEM objects specified in IEC 62056-62 and the OBIS identification system specified in IEC 62056-61 (electricity) and in EN 13757-1 (other than electricity). On the other hand, devices using DLMS/COSEM – e.g. electricity meters or house gateways – may be set up as M-Bus masters, exchanging data with M-Bus slaves. M-bus supports the following physical interfaces: • twisted pair local bus with base band signalling, according to EN 13757-2; • wireless in the unlicensed 868÷980 MHz SRD (Short Range Device) band, according to

EN 13757-4. It is suitable for in-house data exchange, up to 15 m. The action radius can be extended by using the relaying methods specified in EN 13757-5;

• local bus, according to EN 13757-6. M-Bus is a protocol optimised from the point of view of the meter, allowing simple and low cost implementations and long battery life.

6.5.2 Status of standardization The relevant standards are the following: EN 60870-5-1, Telecontrol equipment and systems – Part 5: Transmission protocols – Section 1: Transmission frame formats (IEC 60870-5-1:1990)



Date: 19.06.2009




IEC 60870-5-2:1992, Telecontrol equipment and systems – Part 5: Transmission protocols – Section 2: Link transmission procedures EN 13757-1:2002, Communication system for meters and remote reading of meters – Part 1: Data exchange EN 13757-2:2002, Communication system for meters and remote reading of meters – Part 2: Physical and Link layer EN 13757-3:2004, Communication systems for and remote reading of meters – Part 3: Dedicated application layer EN 13757-4:2005, Communication systems for meters and remote reading of meters - Part 4: Wireless meter readout (Radio meter reading for operation in the 868 MHz to 870 MHz SRD band) EN 13757-5:2008, Wireless meter readout — Communication systems for meters and remote reading of meters — Part 5: Relaying EN 13757-6: 2007, Communication systems for and remote reading of meters. Part 6: Local bus EN 1443-3:2008, Heat Meters - Part 3: Data exchange and interfaces CEPT/ERC/REC 70-03 E, Relating to the use of short range devices (SRD) ETSI EN 300 220-1, V1.3.1:2000, ElectroMagnetic Compatibility and Radio Spectrum Matters (ERM); Short range devices (SRD); Radio equipment to be used in the 25 MHz to 1 000 MHz frequency range with power levels ranging up to 500 mW; Part 1: Technical characteristics and test methods Dutch Smart Metering Requirements (DSMR) – P2 Companion Standard, V2.31 8 P

thP January

2009 DLMS User Association 1000-1:2009, Ed. 9.0: Blue Book: COSEM identification system and interface classes. To accommodate the needs of the Dutch DSMR project and the German OMS project, a revision of the M-Bus standards is foreseen.

6.5.3 Support organization M-Bus is supported by the M-Bus Association: HThttp://www.m-bus.com/ TH



Date: 19.06.2009




6.5.4 Conformance testing and product certification No information is available.


6.5.5.1 Local AMR Supported, either using the twisted pair or the wireless profile.

6.5.5.2 Remote AMR Not supported.

6.5.5.3 AMI Supported, when used in conjunction with DLMS/COSEM.

6.5.5.4 Home Automation Supported.

6.5.6 Summary of technical features For detailed information please refer to Appendix 11.1 in part 1 of this deliverable. In this document only main characteristics are described. 6.5.6.1 The physical and the link layer of the wired (twisted pair) M-Bus profile The physical and the data link layers for data exchange via twisted pairs with base band signalling (there is no carrier signal) are specified in EN 13757-2. Information from the master to the slave is transmitted via voltage level changes. All slaves are constant current sinks: space (0) corresponds to a high current and mark (1) corresponds to a low current. The two wires can be exchanged and they are protected against short circuit. The slave interface can be equipped with an optional reversible mains protection. This option is interesting for devices powered from the mains. Most meters using M-Bus would run on a battery supply, but meters on the twisted pair bus can be optionally supplied from the bus. The total cable length can be a few kilometres. The default baud rate is 300 Bd. Baud rates up to 38,400 Baud are supported. The number of devices on the bus may limit the baud rate to lower values. The data link layer is based on IEC 60870-5-1 and IEC 60870-5-2. The frame format is FT1.2.



Date: 19.06.2009




6.5.6.2 The physical and the link layer of the wireless M-Bus profile The physical and the data link layers for wireless data exchange are specified in EN 13757-4. Three modes of operation are available: • “Stationary mode", mode S, intended for unidirectional or bi-directional communications

between stationary or mobile devices: The S1 mode provides one-way and the S2 mode provides two-way communication. The S2 mode is compatible with KNX (see par. §6.13).

• "Frequent transmit mode", mode T. In this mode, the meter transmits a very short frame (typically 2 ms to 5 ms) every few seconds thus allowing walk-by and/or drive-by readout. There are two sub-modes:

Transmit only sub-mode T1. It is the minimal transmission of a meter ID plus a readout value, which is sent periodically or stochastically.

The bi-directional sub-mode T2 transmits frequently a short frame containing at least its ID and then waits for a very short period after each transmission for the reception of an acknowledge. Reception of an acknowledge will open a bi-directional communication channel.

• "Frequent receive mode", mode R2. In this mode, the meter listens every few seconds for the reception of a wakeup message from a mobile transceiver. After receiving such a wakeup, the device will prepare for a few seconds of communication dialog with the initiating transceiver. In this mode a “multi-channel receive mode” allows the simultaneous readout of several meters, each one operating on a different frequency channel.

The link layer is also based on IEC 60870-5-1 and IEC 60870-5-2 with format class FT3. The frame formats depend on the mode. The baud rates are the following: • T: 67/16 kBaud; • S: 16/16 kBaud • R: 2.4 / 2.4 kBaud. An M-Bus device may support one, several or all modes. The M-Bus wireless protocol is optimised for power consumption and low cost. A battery life of 14 years and a BOM of <1 € is claimed.

6.5.6.3 EN 13757-5: M-Bus wireless relaying EN 13757-5 specifies relaying for wireless networks, to extend the action radius of the radio signal. The following modes are specified: • Mode P, using routers, • Mode R2, protocol using gateways;



Date: 19.06.2009




• Mode Q, protocol supporting precision timing. This mode allows supporting DLMS/COSEM.

6.5.6.4 EN 13757-6: The physical layer for local bus This is an alternative to M-Bus. It is intended for small systems with up to 5 meters, which can be read by a battery operated master. The total cable length is max 50 m. The bus has to be switched on before data exchange.

6.5.6.5 EN 13757-3: The M-Bus dedicated Application layer The Application layer has always a fixed frame structure as described in EN13757-3. It may transport either the dedicated application layer according to EN13757-3 (M-Bus), or alternatively EN13757-1 DLMS/COSEM type communication (primarily used by electricity meters T

3T.

Note that the CI field as the first byte of the application layer distinguishes between these two application layer protocol types and frame structure. All application data are encoded in the bits and bytes of the M-Bus telegrams, carried by the data link layer. An M-Bus telegram contains the following information: • the CI field identifies the type of the telegram: e.g. master to slave, slave to master, lower

layer management information. A range of CI fields are reserved for DLMS based applications;

• the Data header, which can be 12, 4 or 0 bytes long: the 12 bytes “long” header identifies

the device, the device type – e.g. gas, heat, water etc. meters – basic status information and encryption information;

4 bytes: As for CI=7Ah of EN13757-3, If the telegram contains such a “short” header the meter identification is taken from the link layer,

12 bytes: As for CI=72h of EN13757-3, If the telegram contains such a “long” header, this header contains the meter identification.

• the Variable Data Blocks: A VDB consists of the Data Information Block (DIB), the Value

Information Block (VIB) and the Data: The DIB consists of one or more Data Information Fields (DIF). The DIF identifies the

data type, the function (instantaneous, minimum, maximum, during error) and whether the data is current and historical. Extensions are available to identify storage numbers (identifiers of historical data), tariffs and sub-units within a physical device;

The VIB consist of one or more Data Information Fields (VIF). Primary VIFs identify the kind of data: energy, average, instantaneous parameter, the unit and the scaler. VIF extensions are available to further precise the identification.

T

3T SML is not yet referenced in EN 13757-1 (par. §Error! Reference source not found.)



Date: 19.06.2009




The Data field carries the data identified by the DIB and the VIB. • manufacturer specific data. Other application layer standards are: • M-Bus+: Planned future revision of the EN13757-3 (CI-values reserved so far) • DLMS/SML+: EN13757-1, DLMS/COSEM or SML: Planned future revision of the

EN13757-3. The DIB and VIB serve roughly the same purpose as the OBIS codes specified in IEC 62056-61 (electricity) and EN 13757-1 (other than electricity). It should be possible to map the M-Bus identifiers to OBIS codes.

6.5.6.6 Data security M-Bus supports data security by encrypting the M-Bus telegrams, using the DES standard, and more recently, the AES standard. Authentication is not supported.

6.5.6.7 Data exchange between devices using DLMS/COSEM and M-Bus: the Dutch project

This possibility is the result of the Dutch Smart metering project and it is specified in the DLMS UA Blue Book Edition 9. DLMS/COSEM devices, e.g. electricity meters can be set up, using the appropriate interface classes, as M-Bus clients (M-Bus masters) to exchange data with M-Bus slaves, e.g. gas, water, and heat meters. The M-Bus client can retrieve data from M-Bus masters and store these data in COSEM objects. It can also send commands to the M-Bus slave devices. For wireless systems, the T1 and the T2 mode are used. For simple meters, Mode T1 is used. The meters (M-Bus slaves) send their data at regular intervals to the electricity meter (M-Bus master). For more complex meters, Mode T2 is used providing two way data exchange. This allows sending command to the M-Bus slaves to set the date and time and for example actuating a gas valve. The data collected are stored in COSEM objects and can be collected by the Data Collecting System. Whereas EN 13757-3 specifies only DES encryption, the DSMR specification specifies AES. The DSMR specification contains a number of extensions and deviations, which will have to be accommodated in the next revision to the EN 13757 M-Bus standards.



Date: 19.06.2009




Examples for data exchanges between the M-Bus master and slave: • scan for and install new M-Bus slaves; • send operational encryption key; • read / receive M-bus meter registers: real time, hourly and historical values, • set date and time in M-Bus slave; • command M-Bus gas meter valve.

6.5.7 Summary M-Bus is a specification for local – in house – meter data exchange using twisted pair with base-band signalling or by radio in the SDR band. Currently, its main applications are in heat and gas metering. It is optimised for simple devices with battery supply. It can work with DLMS /COSEM in two ways: • the M-Bus lower layers supporting the DLMS/COSEM application layer and data model;

or • DLMS/COSEM devices can be set up as M-Bus masters, exchanging data with meters

using M-Bus and acting as M-Bus slaves.

6.6 Smart Message Language (SML)

6.6.1 Introduction SML is a communication protocol which has been developed and is applied by leading utilities (RWE, E.ON, EnBW, Vattenfall). SML has been applied by various manufacturers (Landis+Gyr, Dr.Neuhaus/Sagem, Hager, EMH, Insys, Goerlitz, ITF-EDV Froeschl and others). SML has been developed to meet the requirements of smart metering/grids which include:

• Suitability for IP-based connections • Consistency of data over more than one level • Clean separation of protocol layers • Support of push and pull procedures • Mix of read/write requests for different devices • Conditional flow of requests in one pack (“if-then-else”) • Capability to create bundled orders without “hand-shake-functions” during the working

process • Sequential or parallel processing of bundled orders • Interoperability across different manufacturers.



Date: 19.06.2009




SML is a non-proprietary standard, whose specification can be accessed free of charge. Currently, version 1.02 is available.

See: Hhttp://www.sym2.org/eng/index_eng.html H. (“SML specification 1.02”)

SML has received substantial support by the SyM² project, in which a clocked load profile meter has been developed by Landis+Gyr, RWE, E.ON, EnBW, the German Federal Ministry of Economics and the University of Kiel.

See: Hwww.sym2.org H

Besides the SyM² project, SML is applied in the following initiatives: • Multi Utility Communication Controller (MUC-C) • New Electronic Domestic Supply Meter (EHZ). The goal involved in drawing up the SML specification was the primary wish to find a maximally simple structure also suitable for implementation in low-power embedded systems than can be used for data procurement over wide-area routes. SML represents a communication protocol for applications in the environment of data procurement and equipment parameterisation. SML only defines the application layer independent from communication layers. Regarding the transport layer it refers to existing standards. Only if a standard transport protocol is not provided, the SML transport frame can be applied. • A clear separation between different layers permits a clean and efficient process of data

transmission. • The accomodation of technological and regulatory changes in the future is also facilitated

by means of a clear separation of layers.



Date: 19.06.2009




Fig. 5 – SML communication model

(SML specification 1.02, Hhttp://www.sym2.org/eng/sml-spezi_eng.htmlH)

6.6.2 Status of standardisation According to the official decision of Working Group DKE AK 461.0.14 of 29 P

thP april 2009, SML

will be prepared to become internationally standardized via the IEC. The working group has decided to work on international standardization right from the beginning rather than first standardizing SML on the national level. Following that decision, SML specification version 1.03 will be passed as a draft by DKE AK 461.0.14 to IEC TC13 WG14 on 30 june 2009. The annex of the SML specification will likewise be passed to IEC TC13 WG14 on 30 P

thP september 2009.

6.6.3 Support organization SML is supported by both DKE AK 461.0.14 and FNN (Forum Network Technology/Mains operation), an independent non-commercial user group.



Date: 19.06.2009




6.6.4 Conformance testing and product certification Currently it is already being worked on concrete test procedures, test requirements and test systems/infrastructure for SML applications in collaboration with test service providers. Within the SyM² project a conformance test procedure already exists which is managed within the group “conformance of metering systems” within VDE-FNN. Further conformance test procedures for SML applications are currently being developed. 6.6.5 Field of application SML is independent from the application and from transport. SML functions as a coder which formats and then compresses data in a similar way as XML or HTML do. However, XML and HTML require too much temporary storage (buffers), whereas SML provides streaming and compressing functions “on the fly”. SML provides the transport container and then the data is coded for transport. Thereby, in the end, the data received can still be divided into its different original components.

6.6.5.1 Local AMR Supported by SML, since SML is independent from transport layer, please see §6.6.1 for general working mechanisms.

6.6.5.2 Remote AMR Supported by SML, since SML is independent from transport layer, please see §6.6.1 for general working mechanisms.

6.6.5.3 AMI Supported by SML, since SML is independent from transport layer, please see §6.6.1 for general working mechanisms.

6.6.5.4 Home Automation Supported by SML, since SML is independent from transport layer, please see §6.6.1 for general working mechanisms.

6.6.6 Data model The data model describes how the single elements of an SML message are built up. Figure 6 illustrates an example of the data model of one SML message. • An SML message is either a ‘Request message’ or a ‘Response message’ • An SML message comprises task and assigned attributes



Date: 19.06.2009




Fig. 6 – SML messages (SML specification 1.02, Hhttp://www.sym2.org/eng/sml-spezi_eng.htmlH)

A SML file, however, is constituted by several SML messages. Figure 7 illustrates that the SML file denotes a specific self-contained information unit, which is completely detached from the transport technology involved (e.g. internet, telephone). In this sense, SML files can be comprehended as self-contained and self-explanatory information units that (just like an email) are embedded and transmitted in a protocol (see Fig 5). The approach of using SML files means the concept is independent of the task of having to define specific protocols for information interchange. Instead, all that is demanded is to select a certain protocol (e.g. HTTP, FTP; ..) in a particular duty case and parameterise this appropriately. If SML files are used as files on computer systems, these files must be noted without the use of additional frames. The coding defined with section 6 of the SML specification then has to be used, unless the particular application involved explicitly specifies a divergent stipulation.

Simple SML file structure

Fig. 7 – SML file structure

(Source: Sym² presentation held at E-world 2008, http://www.sym2.org/docs/EWorld_2008_English.pdf)



Date: 19.06.2009




6.6.7 Communication media supported Basically, any communication media can be used for transmitting SML. For transport of SML files regular standardized procedures for the respective transport medium are used. However, if the transport medium does not provide a protocol for secured data transmission, the SML transport frame can apply which functions as an encoder. This solution is possible for all communication media. SML Structure • The basic SML structure is divided into the following elements:

Smart Message Language defines a file structure/document structure for recording the useful loads between the end points

SML Binary Encoding defines a packed binary coding for SML SML XML Encoding defines the coding for SML in XML SML Transport Protocol, required for serial point-to point links.

• SML messages, can, like an email in the final analysis, be transported over stateless,

secure communication paths. For the duty scenario being targeted, the following model can accordingly be adduced for an overview:

Fig. 6 –SML messages and communication paths

(SML specification 1.02, http://www.sym2.org/eng/sml-spezi_eng.html)



Date: 19.06.2009




6.6.7.1 Local bus Supported by SML, since SML is independent from transport layer, please see §6.6.1 for general working mechanisms.

6.6.7.2 PSTN Supported by SML, since SML is independent from transport layer, please see §6.6.1 for general working mechanisms.

6.6.7.3 GSM Supported by SML, since SML is independent from transport layer, please see §6.6.1 for general working mechanisms.

6.6.7.4 GPRS Supported by SML, since SML is independent from transport layer, please see §6.6.1 for general working mechanisms.

6.6.7.5 Internet Supported by SML, since SML is independent from transport layer, please see §6.6.1 for general working mechanisms.

6.6.7.6 PLC Supported by SML, since SML is independent from transport layer, please see §6.6.1 for general working mechanisms.

6.6.7.7 Walk by radio Supported by SML, since SML is independent from transport layer, please see §6.6.1 for general working mechanisms.

6.6.7.8 Mesh radio Supported by SML, since SML is independent from transport layer, please see §6.6.1 for general working mechanisms.

6.6.8 Summary SML… • .. was developed by utilities to comply with future smart metering requirements:

Suitability for IP-based connections Consistency of data over more than one level Clean separation of protocol layers Support of push and pull procedures Mix of read/write requests for different devices Conditional flow of requests in one pack (“if-then-else”) Capability to create bundled orders without “hand-shake-functions” during the

working process Sequential or parallel processing of bundled orders Interoperability across different manufacturers

• .. is supported by different manufacturers and implemented in different initiatives



Date: 19.06.2009




• .. represents an open and therefore non-proprietary protocol which can be accessed freely

• .. clearly separates communication, application and transport layers which guarantees a clean and efficient process of data transmission Universal applicability to all communication media without having to be adjusted More flexibility with regard to technological and regulatory changes in the future.

6.7 IP Telematric Protocol E-DIN 43863-4 6.7.1 Introduction The specification for IP telemetry originates in products for the procurement of counter readings for the measurement of electrical energy consumption; it can also be used as a generic solution for comparable applications in automation systems and is hence generally useable in the field of machine-to-machine, M2M, interfaces. E-DIN supports Push and Pull via IP-networks as well as migration from traditional leased circuits and point-to-point switched connections to IP-networks.

6.7.2 Status of standardisation “DIN 43863-4 Meter data communication - IP-Telemetry:2006” is a draft standard developed by the Deutsches Institut für Normung (DIN)/ German Institute for Standardization (http://www.dke.din.de/projekte/DIN+43863-4/en/92134004.html). The appropriate WG within DKE at DIN (AK461.0.14) decided already in 2007 to let the (E-) DIN 43863-4 become an international standard. This decision was confirmed in 2008. Due to revision activities the international standardisation was postponed to early 2009. DIN 43863-4 will be passed by DKE AK 461.0.14 to IEC TC13 WG14 on 30 June 2009 to follow its standardisation process.

6.7.3 Support organization This standard is supported by the Institut für Normung (DIN)/ German Institute for Standardization, the national standardisation body in Germany. DIN standards are open and non-proprietary.

6.7.4 Conformance testing and product certification Since E-DIN 43863-4 is also used in the SyM² project (see §6.6.1) it is tested according to those conformance testing procedures. Additionally, E-DIN 43863-4 is accompanied by DKE AK 461.0.14 which plans to develop an individual test infrastructure for this norm.



Date: 19.06.2009




6.7.5 Field of application Generally applicable for all wide area transport via IP-based networks. For transport itself however, regular standardized procedures for the respective transport medium are used.

6.7.5.1 Local AMR Not supported

6.7.5.2 Remote AMR Supported, no specific provisions for Remote AMR

6.7.5.3 AMI Supported, no specific provisions for AMI

6.7.5.4 Home Automation Not supported

6.7.6 Data model Please refer to the following scheme.

Fig. 7 – DIN 86436-4 data model

Application Example IP Telematric in metering (in Germany)

• A transparent communication channel (=migration channel) between meter devices and remote meter readout control center is built up

• Metering data is transported through this channel • In the end, the connection meter/control center equals a “wired” connection, trespassing

several interfaces, though physically there is no connection



Date: 19.06.2009




• Control center can read original data of meter in real time • Set-up permits IP services without having to change entire system. The whole purpose of IP Telematric was the ability to use IP-based services without having to change the entire application. By means of the migration channel IP-based transports can be used without changing IP-Telematric. First, IP is built up, then the channel has been migrated, then migrating the application is possible to use desired applications based on IP-services in an ideal manner.

6.7.7 Communication media supported

6.7.7.1 Local bus Not supported

6.7.7.2 PSTN Supported but independent from communication media used.

6.7.7.3 GSM Supported but independent from communication media used.

6.7.7.4 GPRS Supported but independent from communication media used.

6.7.7.5 Internet Supported but independent from communication media used.

6.7.8 Summary IP Telematric Protocol E-DIN 43863-4 denies any attachement to certain application protocols. The specification arises from products for the procurement of meter readings for the measurement of electrical energy consumption. E-DIN 43863-4 covers regulations concerning the dialling-up of participants. It includes commands - from the simple transfer of measurands and readings to complex appication scenarios in machine-to-machine (M2M) communication. E-DIN supports Push and Pull via IP-networks as well as migration from traditional leased circuits and point-to-point switched connections to IP-networks.

The whole purpose of IP Telematric via E-DIN 43863-4 was the ability to use IP-based services without having to change the entire application. By means of the migration channel IP-based transports can be used without changing IP-Telematric. First, IP is built up, then the channel has been migrated, then migrating the application is possible to use desired applications based on IP-services in an ideal manner.



Date: 19.06.2009




6.8 IEC 60870-5

6.8.1 Introduction IEC 60870-5 provides a communication profile for sending basic telecontrol messages between two systems, which uses permanent directly connected data circuits between the systems. The IEC Technical Committee 57 (Working Group 03) has developed a protocol standard for Telecontrol, Teleprotection, and associated telecommunications for electric power systems. The result of this work is IEC 60870-5. Five documents specify the base IEC 60870-5: • IEC 60870-5-1 Transmission Frame Formats • IEC 60870-5-2 Data Link Transmission Services • IEC 60870-5-3 General Structure of Application Data • IEC 60870-5-4 Definition and coding of Information Elements • IEC 60870-5-5 Basic Application Functions. IEC 60870-5-101 (IEC101) is an international standard prepared by TC57 for power system monitoring, control & associated communications. This is completely compatible with HIEC 60870-5 H-1 to IEC 60870-5-5 standards and uses standard asynchronous serial tele-control channel interface between HDTEH and HDCE H. The standard is suitable for multiple configurations like point-to-point, star, mutidropped etc. Features of IEC 60870-5-101 • Supports unbalanced (master initiated message) & balanced (master/slave initiated

message) modes of data transfer. • Link address and ASDU addresses are provided for classifying the end station and

different sectors under the same. • Data is classified into different information objects and each information object is provided

with a specific address. • Facility to classify the data into high priority (class-1) and low priority (class-2) and

transfer the same using separate mechanisms. • Possibility of classifying the data into different groups (1-16) to get the data according to

the group by issuing specific group interrogation commands from the master & obtaining data under all the groups by issuing a general interrogation.

• Cyclic & Spontaneous data updating schemes are provided. • Facility for time synchronization • Schemes for transfer of files

Types supported by IEC 60870-5-101

• Single indication without / with 24 / with 56 bit timestamps. • Double indication without / with 24 / with 56 bit timestamps. • Step position information without / with 24 / with 56 bit timestamps. • Measured value – normalized, scaled, short floating point without / with timestamps.



Date: 19.06.2009




• Bitstring of 32 bit without / with timestamps. • Integrated totals (counters) without / with timestamps. • Packed events (start & tripping ) of protection equipments • Single commands • Double commands • Regulating step command • Set point commands of various data formats • Bitstring commands • Interrogation commands • Clock synchronization & delay acquisition commands • Test & reset commands Status of standardisation Internationally standardized via IEC

6.8.2 Status of standardisation Open and non-proprietary standard which is internationally standardized via IEC.

6.8.3 Support organization IEC Technical Committee 57 (Working Group 03).

6.8.4 Conformance testing and product certification Information not available.


6.8.5.1 Local AMR Supported.

6.8.5.2 Remote AMR Supported.

6.8.5.3 AMI Not supported.


6.8.6 Data model No Data model available

6.8.7 Communication media supported

6.8.7.1 Local bus Supported.



Date: 19.06.2009




6.8.7.2 PSTN Not supported.

6.8.7.3 GSM Not supported.

6.8.7.4 GPRS Not supported.

6.8.7.5 Internet Not supported.

6.8.7.6 PLC Not supported.

6.8.7.7 Walk by radio Not supported.

6.8.7.8 Mesh radio Not supported.

6.8.8 Summary IEC 60870-5 provides a communication profile for sending basic telecontrol messages between two systems, which uses permanent directly connected data circuits between the systems. The IEC Technical Committee 57 (Working Group 03) has developed a protocol standard for Telecontrol, Teleprotection, and associated telecommunications for electric power systems. The result of this work is IEC 60870-5. IEC 60870-5-101 (IEC101) is an international standard prepared by TC57 for power system monitoring, control & associated communications. This is completely compatible with IEC 60870-5-1 to IEC 60870-5-5 standards and uses standard asynchronous serial tele-control channel interface between DTE and DCE. The standard is suitable for multiple configurations like point-to-point, star, mutidropped etc.

6.9 IEC 61968-9 Source: draft IEC 61968-9, 57/946/CDV.

6.9.1 Introduction Part 9 of the IEC 61968 standard specifies the information content of a set of message types that can be used to support many of the business functions related to Meter Reading and Control. Typical uses of the message types include meter reading, meter control, meter events, customer data synchronization and customer switching. Although intended primarily for electrical distribution networks, IEC 61968-9 can be used for other metering applications, including non-electrical metered quantities necessary to support gas and water networks.



Date: 19.06.2009




The purpose of this document is to define a standard for the integration of Metering Systems (MS), which includes traditional manual systems, and (one or two-way) Automated Meter Reading (AMR) Systems, with other systems and business functions within the scope of IEC 61968. The scope of this standard is the exchange of information between a Metering System and other systems within the utility enterprise. The specific details of communication protocols those systems employ are outside the scope of this standard. Instead, this standard will recognize and model the general capabilities that can be potentially provided by advanced and/or legacy meter infrastructures, including two-way communication capabilities such as load control, dynamic pricing, outage detection, distributed energy resource (DER) control signals and on-request read. In this way, this standard will not be impacted by the specification, development and/or deployment of next generation meter infrastructures either through the use of standards or proprietary means. The capabilities and information provided by a meter reading system are important for a variety of purposes, including (but not limited to) interval data, time-based demand data, time based energy data (usage and production), outage management, service interruption, service restoration, quality of service monitoring, distribution network analysis, distribution planning, demand reduction, customer billing and work management. This standard also extends the CIM (Common Information Model) to support the exchange of meter data.

6.9.2 Status of standardization IEC 61988-9 is a draft standard developed by IEC TC 57.

6.10 SITRED

6.10.1 Introduction In 1992/94 ENEL (largest Italian distribution company) have proceeded to install the first industrial implementation of a Distribution Automation System (DAS) for both supervision of secondary substations and service to customers. This DAS uses a PLC based solution for a two-way telecommunication system using both MV and LV distribution power networks as data transmission media. Two implementations of the communication protocols over the PLC are utilized which differ in the PHY and MAC layers while share the same Application layer. In this way the two PLC implementations are completely transparent from the Central System point of view. One implementation is based on an extension of the Lontalk protocol while the second is based on the ENEL stack named SITRED. Both implementations are currently in use. SITRED (“Integrated System for data Transmission on Electricity Distribution network”) protocol stack is a Enel’s proprietary solution involved in Enel AMM system called



Date: 19.06.2009




“Telegestore”. The Telegestore implementation started in 2001 based on studies and experiments carried out during the previous decade. The following paragraph reports some information about Enel SITRED protocol stack. Further details are given in §6.9.1 in part 2 of this deliverable.

6.10.2 Protocol Layers SITRED protocol implements first, second and seventh layers of ISO stack; some functionalities, typical of unimplemented layers, are embedded on Data Link and Application. • Physical Layer

At physical layer, SITRED protocol stack manages a Frequency Shift Keying (FSK) modulation profile described in IEC 61334-5-2.

• Data Link Layer

At Data Link Layer, SITRED implements repetition features to improve meter’s reachability and the procedure to access to mean in master-slave mode. In addiction, the DL layer is able to manage multiples Application Layers. The Data Link Layer is based on IEC 61334-4-33.

• Application layer (proprietary)

The SITRED’s stack application layer implements all the features needed to implement the data exchange between DLC network’s nodes in a exhaustive way; in addiction it implements some functionality of network management (meter’s auto-discovery and network auto-configuration). At this level, with regard to data security management, Sitred supports encryption, authentication and playback attacks protection.

ENEL’s SITRED does not support GSM and GPRS, except on the back-haul network (out of scope).

6.11 PRIME PRIME (PoweRline Intelligent Metering Evolution) is the definition of the lower layers of a system to provide an open, royalty and patent free solution, for physical and media access control layers, together with certain convergence layers definition, for a narrowband PLC solution in CENELEC A band in the low voltage part of the network. Convergence Layer (CL) opens MAC and PHY layers to upper layers and applications. CL classifies traffic associating it with its proper MAC connection. This layer performs the mapping of any kind of traffic into MAC SDUs, providing access to the core MAC functionalities, as detailed in the following figure.



Date: 19.06.2009




Fig. 8 – PRIME architecture

The IPv4 convergence layer provides an efficient method of transferring IPv4 packets over the PRIME network. The IEC 61334-4-32 Convergence Layer supports the same primitives as the IEC 61334-4-32 standard. For further details, please refer to §3.3 of part 2.

6.12 IEC 61850 Distributed energy resources (DER), Demand Side Management, distribution automation and metering services are functions that all need an open standard for communication. IEC 61850 standard is applicable to describe device models and functions of substation and feeder equipment. There are specific IEC 61850 versions for DER (IEC 61850-7-420) and Wind Power Plants that are important for the OPEN meter project. At this moment, the IEC 61850 series does not include any versions specifically dedicated to residential metering or home automation. The IEC 61850 provides the following features:

• One consistent data model, no complex maintenance of data and no data conversion; • Seamless integration into distribution automation and power control systems; • Using industrial approved technologies. IEC 61850 uses Logical nodes and Logical devices in its data model. The explanation of the logical nodes will follow after explaining the data information.

6.12.1 Data Information Data information models provide standardized names and structures to the data that is exchanged among different devices and systems. Fig. 9 illustrates the object hierarchy used for developing IEC 61850 information models.



Date: 19.06.2009




Logical Nodes

Common Data Class

Common ComponentsStandard Data Types

Logical Nodes (LN)

Common Data Classes (CDC)

Common Attributes

Logical Devices (LD)

Data Objects (DO)

Fig. 9 – IEC 61850 Information model hierarchy

The process from the bottom up is described below: a) Standard data types: common digital formats such as Boolean, integer, and floating

point. b) Common attributes: predefined common attributes that can be reused by many different

objects, such as the quality attribute. These common attributes are defined in Clause 6 of IEC 61850-7-3.

c) Common Data Classes (CDC): predefined groupings building on the standard data types and predefined common attributes, such as the single point status (SPS), the measured value (MV), and the controllable double point (DPC). In essence, these CDCs are used to define the type or format of data objects. These CDCs are defined in IEC 61850-7-3 or in Clause 9 of this document. All units defined in the CDCs shall conform to the SI units (international system of units) listed in IEC 61850-7-3.

d) Data Objects (DO): predefined names of objects associated with one or more Logical Nodes. Their type or format is defined by one of the CDCs. They are listed only within the Logical Nodes. An example of a DO is “Auto” defined as CDC type SPS. It can be found in a number of Logical Nodes.

e) Logical Nodes (LN): predefined groupings of data objects that serve specific functions and can be used as “bricks” to build the complete device. Examples of LNs include MMXU which provides all electrical measurements in 3-phase systems (voltage, current, watts, vars, power factor, etc These LNs are described in Clause 5 of IEC 61850-7-4.

f) Logical Devices (LD): the device model is composed by the relevant Logical Nodes for providing the information needed for a particular device. Logical devices are not directly defined in any of the IEC 61850 documents, since different products and different implementations can use different combinations of Logical Nodes for the same logical device.

6.12.2 Logical nodes for the DER plant ECP logical device The logical device for the DER plant electrical connection point (ECP) defines the characteristics of the DER plant at the point of electrical connection between one or more DER units and any electric power system (EPS), including isolated loads, microgrids and the utility power system. Usually there is a switch or circuit breaker at this point of connection.



Date: 19.06.2009




ECPs can be hierarchical. Each DER (generation or storage) unit has an ECP connecting it to its local power system; groups of DER units have an ECP where they interconnect to the power system at a specific site or plant; a group of DER units plus local loads have an ECP where they are interconnected to the utility power system. In a simple DER configuration, there is one ECP between a single DER unit and the utility power system. However, as shown in Fig. 10, there may be more ECPs in a more complex DER plant installation. In this figure, ECPs exist between:

• each single DER unit and the local bus; • each group of DER units and a local power system (with load); • multiple groups of DER units and the utility power system.

Utility Power System

Load interconnection

DER interconnections

= Electrical Connection Point (ECP)

Point of CommonCoupling (PCC)

Local Bus

Local PowerSystem

PVWind Turbine

Meter

Fig. 10 – Example of ECP for DERs

Building logical devices to automate the operation of a PV system for example would require the following functions:

• Switchgear operation: functions for the control and monitoring of breakers and disconnect devices. This is already covered in IEC 61850-7-4.

• Protection: functions required to protect the electrical equipment and personnel in case of a malfunction. Already covered in IEC 61850-7-4. A PV specific protection is “DC ground fault protection function” that is required in many PV systems to reduce fire hazard and provide electric shock protection. This function is covered by the logical node and described in IEC 61850-7-4.

• Measuring and metering: functions required to obtain electrical measurements like voltage and current. AC measurements are covered in IEC 61850-7-4.



Date: 19.06.2009




• DC to AC conversion: functions for the control and monitoring of the inverter. • Array operation: functions to maximize the power output of the array. These include

adjustment of current and voltage level to obtain the MPP and also the operation of a tracking system to follow the sun movement.

• Islanding: functions required to synchronize the PV system operation with the power system. This includes anti-islanding requirements specified in the interconnection standards.

• Energy storage: functions required to store excess energy produced by the system. Energy storage in small PV systems is usually done with batteries, while larger PV systems may include compressed air or other mechanisms.

Examples of installations with multiple ECPs include the following:

• One DER device is connected only to a local load through a switch. The connection point is the ECP.

• Groups of similar DER devices are connected to a bus which feeds a local load. If the group is always going to be treated as a single generator, then just one ECP is needed where the group is connected to the bus. If there is a switch between the bus and the load, then the bus has an ECP at that connection point.

• Multiple DER devices (or groups of similar DER devices) are each connected to a bus. That bus is connected to a local load. In this case, each DER device/group has an ECP at its connection to the bus. If there is a switch between the bus and the load, then the bus has an ECP at that connection point.

• Multiple DER devices are each connected to a bus. That bus is connected to a local load. It is also connected to the utility power system. In this case, each DER device has an ECP at its connection to the bus. The bus has an ECP at its connection to the local load. The bus also has an ECP at its connection to the utility power system. This last ECP is identical to the IEEE 1547 PCC.

6.13 KNX KNX (Konnex) is a standard for home and building control approved as: • European Standard (CENELEC EN 50090 and CEN EN 13321-1) • International Standard (ISO/IEC 14543-3) • Chinese Standard (GB/Z 20965) • US Standard (ANSI/ASHRAE 135). KNX is therefore future proof. KNX products made by different manufacturers can be combined – the KNX trademark logo guarantees their interworking and interoperability. KNX is therefore the world´s only open Standard for the control in both commercial and residential buildings. This standard is based upon more than 15 years of experience in the market, amongst others with predecessor systems to KNX: EIB, EHS and BatiBUS. Via the KNX medium to



Date: 19.06.2009




which all bus devices are connected (twisted pair, radio frequency, power line or IP/Ethernet), they are able to exchange information. Bus devices can either be sensors or actuators needed for the control of building management equipment such as: lighting, blinds / shutters, security systems, energy management, heating, ventilation and air-conditioning systems, signaling and monitoring systems, interfaces to service and building control systems, remote control, metering, audio / video control, white goods, etc. All these functions can be controlled, monitored and signaled via a uniform system without the need for extra control centers.

6.14 ZigBee SmartEnergyProfile ZigBee is a suite of high level communication protocols using small, low-power digital radios based on the IEEE 802.15.4 standard for wireless personal area networks (WPANs). ZigBee is a registered trademark of the ZigBee Alliance, The ZigBee standard describes in detail the over the air protocol used, however there are a number of layers to consider when looking at ZigBee protocols; 1. MAC layer – uses standard IEEE 802.15.4 messaging for point-to-point communications

in the mesh network. 2. Network Layer (NWK) – ZigBee adds headers for networking in a multi-hop network (end

to end device addressing etc.) and security 3. Application Support Sublayer (APS) – Provides mechanisms for managing end to end

messaging across multiple hops in a mesh network e.g. addressing endpoints in a device, triggering route discovery, managing end-to-end retries

4. ZigBee Cluster Library (ZCL) - ZigBee defines a library of interoperable message types called ‘clusters’ that cover a variety of device types. This library can be added to when creating support for new applications.

The Smart Energy Profile (ZigBee Profile 0x0109) defines device descriptions for Simple Meter Reading, Demand Response and Load Management. Format is defined by the ZigBee specification, in the ZigBee Cluster Library and Application Profiles. Custom protocols / data formats are allowed, but would not be guaranteed interoperable.



Date: 19.06.2009




Fig. 11 – ZigBee layers (Source: www.zigbee.org)

In the US, the project OPEN-AMI (EPRI) planned to use ZigBee for in house communications e.g. among home meters, the Home Gateway and home/building automation (generators, storages and user appliances). For further information, please refer to paragraph §5.4.1 in part 3 of this Deliverable.

6.15 6LoWPAN “IPv6 over Low-Power Wireless Personal Area Networks” (6LoWPAN) is a low-power wireless personal area networks comprising devices that conform to the IEEE 802.15.4-2003 standard by the IEEE [IEEE802.15.4]. IEEE 802.15.4 devices are characterized by short range, low bit rate, low power, and low cost. Some of the characteristics of LoWPANs are as follows:

• Small packet size. Given that the maximum physical layer packet is 127 bytes, the resulting maximum frame size at the media access control layer is 102 octets. Link-layer security imposes further overhead, which in the maximum case (21 octets of overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32 and AES-CCM-64, respectively), leaves 81 octets for data packets.

• Support for both 16-bit short or IEEE 64-bit extended media access control addresses. • Low bandwidth. Data rates of 250 kbps, 40 kbps, and 20 kbps for each of the currently

defined physical layers (2.4 GHz, 915 MHz, and 868 MHz, respectively).



Date: 19.06.2009




• Topologies include star and mesh operation.

6.16 Homeplug Homeplug is a technical specification for powerline communications developed by a consortium of companies. The specifications are available to HomePlug member companies. As an open alliance, any company can become a member and have access to the specifications. Homeplug AV also provides advanced capabilities consistent with new networking standards. Advanced Network Management functions and facilities are capable of supporting user plug-and-play configuration as well as service provider set-up and configuration. HPAV offers tight security based on 128-bit AES and makes provision for dynamic (automatic) change of the encryption keys and for several different user experiences in setting up security and admitting stations to the network. The design allows a station to participate in multiple AV networks. HPAV is backward compatible with HomePlug 1.0 and offers several mandatory and optional co-existence modes enabling multi-network operation, hidden node service and Broadband over Powerline (BPL) co-existence. The Physical Layer (PHY) operates in the frequency range of 2÷28 MHz and provides a 200 Mbps channel rate and a 150 Mbps information rate. Modulation densities from BPSK (which carries 1 bit of information per carrier per symbol) to 1024 QAM (which carries 10 bits of information per carrier per symbol) are independently applied to each carrier based on the channel characteristics between the transmitter and the receiver. An Initiative to develop a common application layer integrated solution for advanced metering infrastructure (AMI) and home area networks (HAN) has started. Using the robust capabilities of the ZigBee Smart Energy public application profile as a baseline, the three groups will expand the application layer and enable it to run on HomePlug technology, providing utilities with both wireless and wired HAN industry standards to select from when implementing new AMI programs. Today is used in homes to network Ethernet devices (thanks to high data rate that support video streaming). HomePlug standard is reasonably mature. For further information, please refer to part 2 of this deliverable and HThttp://www.homeplug.orgTH.

6.17 Z-Wave Z-Wave is a proprietary standard (mesh wireless, especially for home automation); among partners of Z-Wave Alliance are Cooper, Betronic, Black&Decker, Panasonic, Somfy; recently Nokia has launched an home control center based on this standard. Licensing program and technical support is offered.



Date: 19.06.2009




This standard offers 9 600 bit/s communication, based on GFSK modulation; it ranges approximately 30 meters ("open air" conditions). The Z-Wave Radio uses the 900 MHz ISM band: • 908.42 MHz (USA); • 868.42 MHz (Europe); • 919.82 MHz (Hong Kong); • 921.42 MHz (Australia/New Zealand).

6.18 Wavenis Wavenis is a wireless communication platform that only covers PHY, MAC & NET layers (that can support many application protocols), optimized for ultra low power and long range WSNs. The Wavenis Open Standard Alliance (HTwww.wavenis-osa.org TH) which is an independant and a non for profit organization brings Wavenis into a standardization process while taking care of managing specification roadmap. Note that Wavenis-OSA is now considering the adoption of IPSO services for NET layer. For further information, please refer to §5.4.4 in part 3 of this Deliverable.

6.19 EverBlu

6.19.1 Introduction EverBlu is an Automatic Meter Reading system based on wireless mesh point-to-multipoint communication infrastructure for urban, suburban or rural environments. It is suitable for multi-energy applications including water, gas electricity and heat metering.

6.19.2 Status of standardization The LAN layer of EverBlu is coming from the former Radian protocol, designed 10 years ago by a European user association (EDF, GDF, Severn Trent Water, Aquametro, Itron, Schlumberger, Sontex and Viterra). As such, the EverBlu endpoints can be read in dual mode either using EverBlu fixed network or walk-by collection system compatible with Radian protocol.


6.19.3.1 Local AMR Supported with two-way local data exchange based on Radian protocol (originally developed in 1998 by Itron).

6.19.3.2 Remote AMR Supported with two-way remote data exchange over various media (eg GPRS).



Date: 19.06.2009




6.19.4 Summary of technical features EverBlu is an ultra-low-power (bi-power), bi-frequency, long-range (300m), wireless mesh technology, especially for metering applications. EverBlu operates in major license-free bands: • LAN: 433 MHz – 10mW (worldwide) • NAN*: 868 MHz (Europe) – 200mW / 915 MHz – 200mW (Australia)

(*) NAN = neighborhood area network Fixed network application schematic:

Fig. 12 – EverBlu architecture

(www.actaris.com) For further details, please refer to §5.4.11 in part 3 of this Deliverable.



Date: 19.06.2009




6.19.4.1 AMI Supported.

6.19.4.2 Home automation Not supported.

6.20 OPERA/UPA OPERA (Open PLC European Research Alliance) was an R&D EU-funded project under the Sixth Framework Program (Hwww.opera-ist.orgH) which aim was to develop a new-generation PLC technology as an alternative for access in the local loop. Such a standardized technology would enable low cost broadband access for all European citizens with outstanding performance. OPERA started back in January 2004 and finished its first Phase in February 2006. Second Phase lasted from January 2007 to December 2008. The OPERA specification was developed as a result of extensive investigation during the Project life. This is reflected in public Deliverables as output from the Project (D27 of OPERA Phase II). OPERA established a liaison with UPA ( Hwww.upaplc.orgH) to jointly contribute a proposal to the IEEE P1901 group. Although finally the proposal was eliminated, many of the ideas were taken to be included in the baseline IEEE P1901 finally approved (e.g. variable symbol length). OPERA specification still remains as an open PHY and MAC proposal for BPL systems. For additional information, please refer to §5.8.1 in part 2 of this Deliverable.

6.21 ITU-G.hn G.hn is a standard for wired communications developed by the International Telecommunications Union (ITU). The goal of G.hn is to develop a single PHY/MAC standard that can work over any type of wired media, including power lines, phone lines and coaxial cables. Recommendation G.9960, which descrbes the Physical Layer and System Architecture of G.hn, received consent in Dec 2008. Shortly thereafter, multiple silicon vendors announced support for the standard. For additional information, please refer to §5.7.2 in part 2 of this Deliverable.

6.21.1 G.hn Overview G.hn specifies a single PHY based on FFT OFDM modulation and Low-Density Parity-Check (LDPC) FEC code. G.hn includes the capability to notch specific frequency bands to avoid interference with Amateur Radio bands and other licensed radio services. G.hn includes mechanisms to avoid interference with legacy home networking technologies and also with other wireline systems such as VDSL2 or other types of DSL used to access the home.



Date: 19.06.2009




G.hn will provide a data rate of up to 1 Gbit/s. OFDM systems split the transmitted signal into multiple orthogonal sub-carriers. In G.hn each one of the sub-carriers is modulated using QAM. The maximum QAM constellation supported by G.hn is 4096-QAM (12-bit QAM). The G.hn Medium Access Control is based on a TDMA architecture, in which a "domain master" schedules Transmission Opportunities (TXOPs) that can be used by one or more devices in the "domain". There are two types of TXOPs: • Contention-Free Transmission Opportunities (CFTXOP), which have a fixed duration and

are allocated to a specific pair of transmitter and receiver. CFTXOP are used for implementing TDMA Channel Access for specific applications that require Quality of Service guarantees.

• Shared Transmission Opportunities (STXOP), which are shared among multiple devices in the network. STXOP are divided into Time Slots (TS). There are two types of TS:

o Contention-Free Time Slots (CFTS), which are used for implementing "implicit" Token passing Channel Access. In G.hn, a series of consecutive CFTS is allocated to a number of devices. The allocation is performed by the "domain master" and broadcast to all nodes in the network. There are pre-defined rules that specify which device can transmit after another device has finished using the channel. As all devices know "who is next", there is no need to explicitly send a "token" between devices. The process of "passing the token" is implicit and ensures that there are no collisions during Channel access.

o Contention-Based Time Slots (CBTS), which are used for implementing CSMA/CARP Channel Access. In general, CSMA systems cannot completely avoid collisions, so CBTS are only useful for applications that do not have strict Quality of Service requirements.

6.21.2 G.hn security G.hn uses the AES encryption algorithm (with a 128-bit key length) to ensure confidentiality. Authentication and Key exchange is done following ITU-T Recommendation X.1035. G.hn specifies point-to-point security inside a domain, which means that each pair of transmitter and receiver uses a unique encryption key which is not shared by other devices in the same domain. For example, if node Alice sends data to node Bob, node Eve (in the same domain as Alice and Bob) will not be able to eavesdrop their communication. G.hn supports the concept of relays, in which one device can receive a message from one node and deliver it to another node further away in the same domain. Relaying provides extended range for large networks. To ensure security in scenarios with relays, G.hn specifies end-to-end encryption, which means that if node Alice sends data to node Bob



Date: 19.06.2009




using node Mallory as an intermediate relay, the data is encrypted in such a way that Mallory can not decrypt it or modify it. The other alternative (used by IEEE P1901, but not by G.hn) would be hop-by-hop encryption, in which data is sent from Alice to Mallory, decrypted by Mallory, encrypted again by Mallory for delivery to Bob and then decrypted by Bob. In this hop-by-hop scenario, data is available in plain text while it's being relayed by Mallory, which makes the system susceptible to a Man-in-the-middle attack.

6.21.3 G.hn Layered reference model G.hn specifies the Physical Layer and the Data Link Layer, according to the OSI model.

Fig. 13 – G.hn layered model

The G.hn Data Link Layer is divided into three sub-layers: • The Application Protocol Convergence (APC) Layer, which accepts frames (usually in

Ethernet format) from the upper layer (Application Entity) and encapsulates them into G.hn MAC Service Data Units (MSDUs). The maximum payload of each MSDU is 2P

14P

bytes. • The Logical Link Control (LLC), which is responsible for encryption, aggregation,

segmentation and Automatic repeat-request. This sub-layer is also responsible for "relaying" of MSDUs between nodes that may not be able to communicate through a direct connection.

• The Medium Access Control (MAC), which schedules Channel Access.



Date: 19.06.2009




The G.hn Physical Layer is divided into three sub-layers: • The Physical Coding Sub-layer (PCS), responsible for generating PHY headers. • The Physical Medium Attachment (PMA), responsible for scrambling and FEC

coding/decoding. • The Physical Medium Dependent (PMD), responsible for bit-loading and OFDM

modulation. The PMD sub-layer is the only sub-layer in the G.hn stack that is "medium dependent" (ie, some parameters may have different values for each media - power lines, phone lines and coaxial cable). The rest of sub-layers (APC, LLC, MAC, PCS and PMA) are "medium independent". The interface between the Application Entity and the Data Link Layer is called A-interface. The interface between the Data Link Layer and the Physical Layer is called Medium Independent Interface (MII). The interface between the Physical Layer and the actual transmission medium is called Medium Dependent Interface (MDI).

6.21.4 G.hn industry support Multiple organizations, including HomeGrid Forum, Universal Powerline Association (UPA), HomePNA, Consumer Electronics Powerline Communications Alliance (CEPCA), Broadband Forum have expressed support for the standard. Multiple silicon and IP vendors, including DS2, Coppergate, Ikanos and Aware have announced plans to support G.hn in future products. Large silicon vendors like Intel, Infineon, Texas Instruments; Consumer Electronics vendors like Panasonic; CE retailers like Best Buy; have expressed support for G.hn as the single next generation standard for wired networking.

7 CONCLUSIONS The combination of AMI applications (such as Demand Side Management, Distribution Automation, Outage Management, Reduction of Energy Usage, Efficient Customer Switching, decrease of network losses, local balancing by load and generation control) could build a solid business case. But is is also this combination that requires a standards based AMI so that they all can make use of the same infrastructure and seamlessly integrate. Several manufacturers/utilities are proposing their own AMI proprietary solutions, and even if applications are quite similar, there is an important lack of interoperability among these systems, which prevents the large scale adoption of the smart multi metering technology. Although there are various reference models for Smart Metering, as described in this document, some gaps are identified and will have to be filled within this project.



Date: 19.06.2009




8 TCOPYRIGHT “Copyright and Reprint Permissions. You may freely reproduce all or part of this paper for non-commercial purposes, provided that the following conditions are fulfilled: (i) to cite the authors, as the copyright owners (ii) to cite the OPEN meter Project and mention that the European Commission co-finances it, by means of including this statement “OPEN meter. Energy Project No 226369. Funded by EC” and (iii) not to alter the information.”

Documents

OPEN-Meter WP2 D2.1 Part4 v1.0