Smart Grid Comm 2011 Final

5/12/2018 Smart Grid Comm 2011 Final - slidepdf.com

http://slidepdf.com/reader/full/smart-grid-comm-2011-final 1/6

Comparison of the Communication Protocols

DLMS/COSEM, SML and IEC 61850 for Smart

Metering Applications

Stefan Feuerhahn∗, Michael Zillgith∗, Christof Wittwer∗ and Christian Wietfeld†

∗Dept. Electrical Energy Systems

Fraunhofer Institute for Solar Energy Systems, Freiburg, Germany

Email: [email protected]†Communications Networks Institute (CNI), Dortmund University of Technology, Germany

Email: [email protected]

Abstract—Communication technology plays an increasinglyimportant role in the growing automated metering infrastructure(AMI) market. This paper presents a thorough analysis andcomparison of four application layer protocols in the smart

metering context. The inspected protocols are DLMS/COSEM,the Smart Message Language (SML), and the MMS and SOAPmappings of IEC 61850. The focus of this paper is on theiruse over TCP/IP. The protocols are first compared with respectto qualitative criteria such as the ability to transmit clocksynchronization information. Afterwards the message size of meter reading requests and responses and the different binaryencodings of the protocols are compared.

I. INTRODUCTION

Advanced metering infrastructure (AMI) systems are

quickly growing in number and size. They consist of smart

meters in households that support two-way communication to

the back office of the meter service provider. The effort to

install these infrastructures is mainly driven by three goals:1) Give consumers more feedback about their consumption

and costs and thereby promote economizing behavior.

2) Promote the shift of resource usage from times of high

demand to times of low demand.

3) Create an infrastructure that can be readily used for other

smart grid applications in the distribution grid.

Smart metering communication is the focus of several

standardization efforts (e.g. [1]) and part of national smart

grid roadmaps [2] [3]. But up to now the majority of the

installed AMIs uses proprietary protocols that do not conform

to open or international standards. In the future though it

will be necessary to focus on open standards. This will allow

competition on a free market leading to lower prices.

In this paper four different application layer protocols are

compared with regard to their support for smart metering

applications. By Application Layer we refer to the layer of

the Internet Protocol Suite, which includes the Session and

Presentation Layer of the OSI model and sits on top of TCP or

UDP. The protocols under investigation are the Smart Message

Language (SML, IEC 62056-58 Draft) [4], DLMS/COSEM as

defined in IEC 62056-53 [5] and IEC 62056-62 [6], and the

MMS [7] and SOAP [8] mappings for the IEC 61850 standard.

Smart metering protocols have been analyzed in differ

ent ways in the past. In [9] a general overview of th

most common smart metering protocols at all layers is pre

sented. In [10] protocols were briefly compared with respecto their support for demand response applications. In [11

DLMS/COSEM is thoroughly compared to IEC 60870-5-104

In [12] DLMS/COSEM is analyzed in detail. This paper is th

first to compare DLMS/COSEM, SML and IEC 61850 based

on qualitative criteria and coding efficiency.

This paper is organized as follows: In Section II the mos

common smart metering communication topologies are looked

at. It is pointed out where the protocols under investigation can

be used. In Section III the qualitative criteria are discussed by

which the protocols are analyzed and compared in Section IV

Section V analyzes the message size and coding efficiency o

the protocols. Finally a conclusion is drawn.

I I . SMART METERING COMMUNICATION TOPOLOGY

Many different network topologies are being used for AMIs

Most topologies though can be derived from the general form

displayed in Figure 1. In this figure the electricity, gas, water

and heat meters communicate with a home gateway which

acts as the interface to the outside world. In many scenario

this gateway is actually integrated in the electricity meter. In

this case the communication line (a) in Figure 1 will no

be needed. Gas, water, and heat meters are special in tha

they are mostly battery driven. This has to be accounted fo

when choosing a communication protocol for (b). The gateway

(or electric meter) can then communicate with the utility (o

metering service provider) directly over the Internet (c) or with

a concentrator as an intermediate step (d, e), where (d) i

usually a power line or mid-range wireless solution.

The application layer protocols that we look at can all be

used over the TCP/IP protocol stack and are thus applicable fo

Internet communication on (c) and (e) and over local networks

such as Ethernet and Wi-Fi on (a). In addition the protocols can

be used over other lower layer protocols. DLMS/COSEM can

be used over UDP, HDLC, Meter-Bus, and different narrow

band power line protocols such as IEC 61334-5. SML can be



Fig. 1. Smart Metering Communication Topology

used over serial lines and Meter-Bus. MMS and SOAP do not

support any additional lower layer protocols.

III. QUALITATIVE CRITERIA

In this section we describe the qualitative criteria by which

we analyze and compare the protocols in Section IV.

A. Information Type Support

Smart metering application layer protocols can be compared

regarding their support to transport different types of informa-

tion. AMIs need communication technology to usually transfera subset of the following information items to and from the

smart meter:

• Measured Data - Naturally all protocols under investiga-

tion support the communication of measured data such

as energy, power, voltage, or volume. But the protocols

can differ by their support for:

– Load Profile - A meter could store load profiles (e.g.

with a resolution of 15 min.). The protocol would

need to support the transmission of these profiles,

optionally with associated timestamps.

– Digital Signature - Measured data might have to be

associated with digital signatures in order to provethe integrity of the data to third parties.

• Clock Synchronization Data - A synchronized clock is

important for meters that store load profiles or meters

that switch dynamically between tariff registers based on

a timetable.

• Firmware Updates - As gateways or meters and their

communication modules are getting more complex it be-

comes useful to be able to update the firmware remotely

to fix vulnerabilities or add features.

• Pricing Information - Communication of pricing informa-

tion can be realized in many different ways. An analysis

of different approaches to communicate tariffs and a

protocol comparison was done in [13]. This paper doesnot analyze the protocols regarding their tariff support.

B. Ability to Push Metering Data

Application Layer protocols can follow a strict client-server

principle in that connections or associations can only be started

by the client. In the metering environment the server would

usually be within the device that stores the meter data (e.g.

the meter itself) and the client would be the entity that wants

to access the data or set parameters.

Protocols can also be based on a peer-to-peer principle in

that the two communication entities have equal capabilities

At any point in time an entity can act as a client or a server

This principle allows a more flexible use of the protocol since

meters have the capability to send (actively push) data to other

without the need of an open association that was started by

the client.

C. Availability of an Interface Object Model

In the client-server oriented protocols, DLMS/COSEM and

IEC 61850, the server contains what we call an interface objec

model which represents the server device (e.g. the meter)

This model is built in an object oriented fashion and acts as

the visible information interface to the client. The client can

retrieve the interface object model in a standardized way using

the protocol and thus does not need to know in advance abou

the exact setup and functionality of the server. We also speak

of a self-descriptive server in this case. A retrievable interface

object model can make things easier in that a client can be

programmed to automatically respond to different models. Bu

it also cements the client-server structure since the servealways contains the interface object model.

D. Built in security mechanisms

As more smart meters are installed the security of the AM

systems requires more attention. A protocol can have buil

in security mechanisms such as encryption or leave this to a

lower layer protocol such as Transport Layer Security (TLS)

IV. QUALITATIVE ANALYSIS

A. SML

The Smart Message Language (SML) was developed as par

of the Synchronous Modular Meter (SyM2) project [14]. In

Germany SML is widely used and is part of the major smar

metering standardization effort [15]. So far SML is rarel

used outside of Germany but this might change if the effor

to make SML an international standard is successful. In any

case it will be helpful to compare the international standard

DLMS/COSEM and IEC 61850 to SML. This might lead to

valuable improvements in these existing standards.

SML is different from DLMS/COSEM and IEC 61850

in that it defines messages instead of defining an interfac

object model and services to access it.1 SML uses a form

similar to ASN.1 to specify hierarchical message structures

The messages are coded with a special encoding which wil

be thoroughly discussed in Section V. A message is either request or a response message. But a response message can

be sent without a request. Thus SML does not enforce a stric

client-server principle and meter data can be actively pushed

by the meter.

The message format supports the transmission of load

profiles and their associated digital signatures. The communi

cation of new firmware and clock synchronization is possibl

1Future enhancements of SML shall support access to the COSEM interfacobject model but this is not considered here.



but the exact standardization is left to other standardization

bodies (e.g. [14]).

SML has no built in security except for simple username and

password fields inside the SML messages. For communication

over TCP/IP, the SSL/TLS protocol can be used.

B. DLMS/COSEM

The Device Language Message Specification (DLMS) and

COmpanion Specification for Energy Metering (COSEM)

form together the DLMS/COSEM application layer commu-

nication protocol [5] and an interface model for metering

applications [6]. Using the wrapper layer defined in [16],

DLMS/COSEM can be used over TCP/IP and UDP/IP.

DLMS/COSEM is based on a strict client-server structure.

The server is meant to be within the meter while the client

accessing the meter could be a gateway or the central office.

Other use cases where the server is within the gateway and

the client is in the central office are also feasible.

Before the actual metering information can be exchanged

an association has to be build up, which is initiated by the

client. The DLMS client can then access the interface objectmodel inside the server. Once an association exists the DLMS

server is also able to send notifications to the client without

an explicit request.

DLMS/COSEM supports clock synchronization and trans-

mission of measurement profiles. So far DLMS/COSEM as

standardized in [5] and [6] neither supports the transmission

of digital signatures with measurement data nor a firmware

download. Both will be supported in the future. Data objects

for firmware updates are already part of the Blue Book Ed.

10. Support for digital signatures is being worked on by the

DLMS User Association.

DLMS/COSEM includes authentication and confidentiality

services based on symmetric encryption. The protocol does notallow the use of TLS/SSL which could realize these services

with asymmetric keys. Support for asymmetric encryption is

being worked on by CENELEC in WG 02 of TC 13.

C. IEC 61850

The MMS and SOAP mappings of IEC 61850 do not differ

regarding the support of the features analyzed here. For this

reason the following applies to both protocols.

IEC 61850 is a group of standards originally designed for

the use in substation automation. By now the standard has

been extended for controlling hydroelectric power plants [17],

wind turbines [18], and other distributed energy resources [19].

In [19] the DLMS/COSEM and ANSI C12.19 standards are

referred to for revenue metering. IEC 61850 shall only support

those metering applications that have no billing requirements.

This distinction between revenue metering and other metering

seems to be more a political than a technical decision. There

is no technical reason why IEC 61850 should not be used for

revenue metering.

IEC 61850 works according to the same client-server princi-

ple as DLMS/COSEM. The server includes an interface object

model which can be accessed through standardized services.

TABLE IQUALITATIVE COMPARISON OF SML, DLMS/COSEM, AN D IEC

61850

Protocols

Feature SML DLMS IEC 61850

Load Profile X X X

Digital Signature X -2 -

Clock Synchronization - X X

Firmware Update -1 -2 -

Push Metering Data X O2 O

Interface Object Model O X X

Includes Security Mechanisms O X O

X = is supported by this protocolO = is not supported by this protocol- = is not supported by this protocol but could be easily extended

1 is standardized in [14]2 is being worked on by the DLMS User Association

How the communication of these services is realized depend

on the concrete communication mapping (e.g. MMS or SOAP

that is being used.

The interface object model of IEC 61850 consists of freely

composable Logical Devices (LD). The LDs consist of two

or more Logical Nodes (LN). IEC 61850-7-4 defines th

LN MMRT for metering. Combined with the logging and/o

reporting services this LN can be used to transmit load profiles

Digital signatures are not part of the LN and are thus no

supported. A firmware update mechanism is also not part o

the IEC 61850 standard. For time synchronization both th

MMS and the SOAP mapping refer to the SNTP protocol.

When using the MMS mapping, the server can send data

without an explicit request through the IEC 61850 reporting

mechanism. An association and thus an open TCP sockeconnection has to be initiated by the client beforehand. The

SOAP mapping does not support the active reporting by the

server.

Neither the MMS nor the SOAP mapping has any built in

security. This is left to the TLS/SSL protocol as recommended

by [20].

D. Comparison

The support for the various qualitative features is summa

rized in Table I. The most significant difference between SML

and the other two protocols is that SML does not rely on

an information model interface and thus does not emphasize

the standardization on the functional level. This leaves moreflexibility in the use of the protocol but also means tha

details (e.g. the message types supported by a device) hav

to be specified by other standardization bodies in order t

guarantee interoperability. SML is the only protocol to suppor

the communication of digitial signatures.

DLMS/COSEM has the advantage over SML that it i

already an international standard that is widely used in Europe

Numerous parties are working to add missing features t

the standard. The fact that DLMS/COSEM specifies its own



security mechanism is not necessarily an advantage. This way

it restricts the security to symmetric key encryption. If meters

should combine their measured data with digital signatures the

meter would need asymmetric keys anyways and could use the

same key pairs for SSL/TLS, if this were allowed.

IEC 61850 has the advantage that it can also be used

for other smart grid applications besides smart metering.

At this moment though there does not seem to be enough

interest in making it a feature rich protocol for smart metering

applications.

V. EFFICIENCY ANALYSIS

In the previous section the protocols have been analyzed

with respect to qualitative features. In this section the ef-

ficiency of the different protocols is analyzed. In particular

the total number of bytes transmitted by each protocol is

examined. Comparing the protocols is not trivial because they

support the communication of different information types, use

different message structures, and different encoding schemes.

For that reason one application namely the access to in-

stantaneous metering readings was chosen for comparison in

the following subsection. Afterwards the different encoding

schemes are directly compared.

A. Access Instantaneous Meter Readings

Getting instantaneous meter readings is a fundamental ap-

plication that is supported by all four protocols. For that reason

it was chosen as the main application for comparison. Meter

readings can be different measurements from the same meter

(e.g. instantaneous power, total energy from electricity meter)

or measurements from several meters requested from a device

such as a gateway.

First the mechanism for retrieving meter readings is de-

scribed for each protocol separately then their message sizesare compared. The four protocols use the following methods

to access the instantaneous meter readings:

• SML specifies the GetList message to get instantaneous

measurement values. The request message contains the

names of parameters or parameter lists that are to be read.

The response contains the requested list of values. Two

scenarios have been analyzed:

– The SML meter or gateway was pre-parameterized

with a list of parameters that are to be read together.

This way only a single list name can be sent to

the server and the response will contain all parame-

ters/values associated with that list name.

– The meter or gateway was not pre-parameterized andall desired readings have to be explicitly requested.

• DLMS/COSEM specifies the Get service to retrieve in-

stantaneous meter readings. A Get-Request can contain

a list of so called COSEM Attribute Descriptors which

unambiguously define the exact parameters to be read.

The response then contains the list of the parameter

values without repeating the associated descriptors again.

• IEC 61850 offers services to manage and access so

called Data-Sets. This way a Data-Set containing an

arbitrary number of data points can be dynamicall

created. Afterwards the data-set can be retrieved using

the GetDataSetValues service in an efficient manner.

In the following, the size of the respective request an

response messages is determined. More precisely, equation

for the TCP Service Data Unit (SDU) size as a function o

the number of measurement values requested are determined

Several parameters in the request and response messages are ovariable length. In the following analysis the shortest possible

parameter length was always chosen. Many different dat

points can be requested by the protocols. In order to b

able to compare the protocols we only regard the request fo

measurement values in the form of four byte integers. Th

packet size was determined partly by implementing the actua

communication protocols [21] and capturing the traffic and

partly by using analytical models.

For SML the TCP SDU size of the request and response

messages is composed as follows:

SML Req = S M L T P V 1 + OpenReq+ GetListReq + CloseReq

+ StuffedBits

SML Res = S M L T P V 1 + OpenRes

+ GetListRes + CloseRes

+ StuffedBits

(1

SML can potentially be used with different encodin

schemes, but in practice only the SML Binary Encoding

is used. For the non pre-parameterized scenario the size o

GetListReqPDU in bytes for the transmission of x values using

the SML Binary Encoding can be estimated by:

SML Req = 16 + 28 + 30x + 19 + 0

SML Res = 16 + 27 + 45x + 19 + 0

The following estimates the size in the pre-parameterized

scenario:

SML Req = 16 + 28 + 30 + 19 + 0

SML Res = 16 + 27 + (26 + 19x) + 19 + 0

The composition and size of the DLMS/COSEM TCP SDUs

for the transmission of x values is as follows:

DLMS Req = T CP Wrapper + GetReqWithList

= 8 + (4 + 11x)

DLMS Res = T CP Wrapper + GetResWithList

= 8 + (4 + 6x)

(2

The composition and size of the MMS TCP SDUs is shown

in (3).



TABLE IITCP PAYLOAD SIZE IN BYTES AS A FUNCTION OF THE NUMBER OF MEASUREMENT VALUES REQUESTED (X)

Protocols

Messa ge Type SML SML preparametrize d D LMS IEC 61 850 MMS IEC 61 850 SOAP

Request 63 + 30x 93 12 + 11x 64 433

Response 62 + 45x 88 + 19x 12 + 6x 30 + 6x 288 + 32x

0

200

400

600

800

1000

1200

1400

1600

5 10 15 20 25 30

T C P

p a y l o a d s i z e i n b y t e s

Number of measurement values transfered

SMLSOAP

SML-preparMMS

DLMS

Fig. 2. Response Messages

MMS Req = RF C 1006 and ISO 8073

+ IS O 8327 Session

+ ISO P resentation

+ MM S GetListReqP DU

= 7 + 4 + 9 + 44

MMS Res = RF C 1006 and ISO 8073

+ IS O 8327 Session+ ISO P resentation

+ MM S GetListResPDU

= 7 + 4 + 9 + (10 + 6x)

(3)

The composition and size of the SOAP TCP SDUs is shown

in (4).

SOAP Req = SOAP Header + SOAP Req XML

= 197 + 236

SOAP Res = SOAP Header + SOAP Res XM L

= 113 + (175 + 32x)

(4)

The resulting sizes are summarized in Table II. In addition

the response message size is graphed in Figure 2. It can be

seen that DLMS and MMS are the most efficient protocols

with respect to message size. It has to be noted though that

DLMS and IEC 61850 require an existing open association

for their message exchange. SML does not need this. The

overhead by the association was not taken into account for

these calculations. If the association is built up once and kept

up for long time periods the overhead will be negligible.

TABLE IIICOMPARING THE BINARY ENCODING LENGTH IN BYTES

Encodings

Message Type SML DLMS

A-XDR

MMS

BER

TL1 Val2 TL Val TL Val

MMS (choice) 0 0 0 0 0 0

confirmed-Resp. (Seq) 3 0 1 0 2 0

invokeID: 458 (Unsigned32) 1 2 0 2 2 2

confServiceResp (choice) 0 0 0 0 0 0

read (Seq) 3 0 1 0 2 0

variableAccessSpec(optional) not opted

1 0 1 0 0 0

ListOfAccessRes (SeqOf) 1 0 1 0 2 0

AccessRessult (SeqOf) 1 0 2 0 2 0

Data: boolean 1 1 1 1 2 1

Data: visible-str = test 1 4 1 4 2 4

sum 12 7 8 7 14 7

sum (TL + Val) 19 15 21

1 length of the Type-Length field2 length of the encoded value

B. Binary Encodings Compared

MMS, DLMS/COSEM, and SML all use byte oriented

binary encodings to encode their messages. In this section they

are compared directly.

MMS uses the BER encoding to encode the message

specified using ASN.1. DLMS/COSEM also uses BER for the

association messages but once associated the payload is coded

using special encoding rules called A-XDR as defined in [22]

A-XDR can only encode a subset of ASN.1 and was developed

to reduce the overhead caused by BER. SML also defines a

new encoding called the SML Binary Encoding. It has th

same goal as A-XDR to reduce the message size compared to

the BER. Both focus on coding type and length fields moreefficiently than BER. While BER usually codes one byte fo

the type field and one byte for the length, in SML Binar

Encoding, the type and length are encoded in one byte i

possible. In A-XDR the type and length fields are omitted

completely where feasible.

The three binary encodings are compared by encoding an

MMS GetDataValues Response message. Table III shows the

number of bytes necessary to code the different component

of the MMS message.



As can be seen, A-XDR needs the fewest bytes to encode

the packet. A-XDR encodes as efficiently as BER or better

in all cases except for optional fields that are not opted. The

SML Binary Encoding does not code with fewer bytes in all

cases. That is because tags in choices are coded with at least

two bytes. All savings in A-XDR and SML Binary Encoding

are in the type and length fields. The actual values are encoded

with equal number of bytes.

V I . CONCLUSION

In this paper the most significant qualitative features of a

smart metering application layer protocol have been identified.

The comparison of DLMS/COSEM, SML, and IEC 61850 has

shown that no single protocol is superior in all aspects. The

analysis and comparison of the message size has shown that

DLMS and the MMS IEC 61850 clearly outperform the rest.

Both DLMS/COSEM and SML use special encodings to code

more efficiently than BER but the SML Binary Encoding has

significant drawbacks when encoding tags of ASN.1 choice

elements. A-XDR does a good job in reducing the overhead

caused by the type and length fields.In the future it would be interesting to do a similar com-

parison using other promising protocols such as ZigBee Smart

Energy 2.0 and ANSI C12.19.

REFERENCES

[1] E. Commission, “M/441 EN, standardisation mandate to CEN, CEN-ELEC and ETSI in the field of measuring instruments for the develop-ment of an open architecture for utility meters involving communicationprotocols enabling interoperability,” Mar. 2009.

[2] NIST, “NIST framework and roadmap for smart grid interoperabilitystandards, release 1.0,” 2010.

[3] DKE, “Die deutsche normungsroadmap E-Energy/Smart grid,” Apr.2010.

[4] S. P. Group, “Smart message language (SML) v. 1.03,” Dec. 2008.[5] “IEC 62056-53 - data exchange for meter reading, tariff and load control

– part 53: COSEM application layer,” 2006.[6] “IEC 62056-62 - data exchange for meter reading, tariff and load control

– part 62: Interface classes,” 2006.

[7] “IEC 61850-8-1 ed1.0 - communication networks and systems in substations - part 8-1: Specific communication service mapping (SCSM- mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC8802-3,” May 2004.

[8] “IEC 61400-25-4 ed1.0 - wind turbines - part 25-4: Communicationfor monitoring and control of wind power plants - mapping to communication profile,” 2008.

[9] K. D. Craemer and G. Deconinck, “Analysis of state-of-the-art smarmetering communication standards,” Leuven, 2010.

[10] S. Mohagheghi, J. Stoupis, Z. Wang, Z. Li, and H. Kazemzadeh, “De

mand response architecture: Integration into the distribution managemensystem,” in Smart Grid Communications (SmartGridComm), 2010 Firs

IEEE International Conference on, 2010, pp. 501–506.[11] A. Zaballos, A. Vallejo, M. Majoral, and J. Selga, “Survey and perfor

mance comparison of AMR over PLC standards,” Power Delivery, IEEETransactions on, vol. 24, no. 2, pp. 604–613, 2009.

[12] T. Otani, “A primary evaluation for applicability of IEC 62056 to Next-Generation power grid,” in Smart Grid Communications (SmartGridComm), 2010 First IEEE International Conference on, 2010, pp67–72.

[13] S. Feuerhahn, M. Zillgith, and C. Wittwer, “Standardized communicatioof Time-of-Use prices for intelligent energy management in the distribution grid,” in VDE Kongress 2010 - E-Mobility, Leipzig, GermanyNov. 2010.

[14] SyMProjectGroup, “SyM - general specification for synchronous modular meters,” Oct. 2009.

[15] VDE, “Lastenheft MUC - multi utility communication, version 1.0

May 2009.[16] “IEC 62056-47 - data exchange for meter reading, tariff and load contro

– part 47: COSEM transport layers for IPv4 networks,” 2006.[17] “IEC 61850-7-410 ed1.0 - communication networks and systems fo

power utility automation - part 7-410: Hydroelectric power plants communication for monitoring and control,” Aug. 2007.

[18] “IEC 61400-25-2 ed1.0 - wind turbines - part 25-2: Communicationfor monitoring and control of wind power plants - information models,Dec. 2006.

[19] “IEC 61850-7-420 ed1.0 - communication networks and systems fopower utility automation - part 7-420: Basic communication structure –distributed energy resources logical nodes,” Oct. 2009.

[20] “IEC/TS 62351-1 ed1.0 - power systems management and associateinformation exchange - data and communications security - part 1Communication network and system security - introduction to securitissues,” May 2007.

[21] “openMUC - software platform for energy gate

ways,” http://www.openmuc.org/, 2011. [Online]. Availablehttp://www.openmuc.org/

[22] “IEC 61334-6 - distribution automation using distribution line carriesystems – part 6: A-XDR encoding rule,” 2000.

Documents

Smart Grid Comm 2011 Final