rdlms

w
I

DLMS - the Application Protocol for communicating meters

i '

SOMOGYI Tibor
Schlumberger - Electricity Technology Laboratory
B.P. 620-05,92542 Montrouge CEDEX, FRANCE
Tel.: (+33) 1.47.46.63.79 Fax.: (+33) 1.47.46.66.88
email.: somogyi@montrouge.em.slb.com

1. Introduction

Standardisation of a messaging system - DLMS originally stands for Distribution Line

Message specification' - is one of the most important events in the meter communications
domain. The existence and the growing popularity of this standard clearly shows that the
Energy Industry is beginning to recognise the importance of a non-proprietery, internationally
standardised communications protocol for its own needs. In fact, the current status is very
similar to the situation of the Telecom Industry some years ago when data communications
started: based on new needs, new applications and new devices were emerging, but these new
developments were isolated from each other and thus were not interoperable.

The Telemm Industry soon recognised that the issue is not to fight for a share of a
small cake - based on proprietary protocols - but to develop together a very big market to
share a very big cake. This recognition implied a considerable international effort which
resulted in the Open System Interconnection ( OSI ) Architecture model [ 1. ] - published in
1984 by the ISO. Since its birth most of the communication standards2 have been based on
this - widely explained, understood and misunderstood, criticised, but mainly accepted and
used - layered model, and the Telecom Industry has reached the original goal: the Telecom
-
cake nowadays is really big and it's worth noting - all players ( Telecom Service providers,
manufacturers and also the end users ) draw benefit from that big cake.

Although communications systems have already been used by the Energy Industry -
mainly by electricity suppliers - assisting in the management of energy production and supply
( referred to as Distribution Automation applications ), new applications - remote meter
reading, tariff control, etc..., ( referred to as Customer Automation applications ) - have
recently appeared also requiring communications. Lots of pilot projects are also in progress,
but most of these new developments are isolated, use proprietary protocols and result in non-
interoperable products.

' DLMS has been recently re-baptised t d ~ e v i c eLanguage Message Specification

Even standards, which are not directly related to the OSI model ( e.g. Internet Protocol Suite ) borrow
fundamental principles ( layers, services, protocol data units, etc...) from this model.

Somogyi Tibor/Schlumbergrr Essen, April 2-4.1997 Page 1 of 8

somogyi@montrouge.em.slb.com --
 rdlms
P
Recognising the similarity to the Telecom situation as it was a few years ago, the
International Electrotechnical Commission ( IEC ) is standardising DLMS to provide -a
'common language' for all kinds of communicating applications of the Energy Industry: the
main objective is to ensure interoperability of meters and other communications
equipments (metering h t a concentrators, etc... ) of a meter communications network, built
on the DLMS basis. At the same time DLMS based communication is simplq enough - it
should be implemented in meters, which generally do not have a lot of resources -,
independent on the metering application - open for new applications - and also independent on
the communications medium. How DLMS accomplishes it and what is the actual status of
DLMS are the main topics of this paper.

2. The two 'faces' of DLMS

2.1 The DLMS Object Model

The basis of DLMS is an object oriented application model. It makes use of a method
called 'abstract object modeling' in order to fully describe the DLMS device model and the
DLMS service procedures. In this modeling technique abstract object types with their
attributes and operations are described.

In order to keep DLMS relatively simple, the DLMS model specifies only a few - five -
object types. Each object type has a name, by which it may be referenced. The outmost object
type, which models a real application is called Virtual Distribution Equipment or VDE. All
the other four DLMS object types are existing only within the VDE. These objects fall in two
categories as follows:

Resources: Data Set7Task Invocation and Variables ( Named Variables, Named

Variable Lists and Message Boxes are all DLMS Variable types ) are virtual
objects representing resources of the real device.
The Virtual Application Association ( VAA ) object. This object is related to the
communications feature, and represents an Application Association. (See at 2.2.)

Figure 1. - The Virtual Distribution ~ ~ u i ~ m e n t )

'fhe VDE Handler and the Tasks are not modeled as objects.
 Note that all these objects are interface objects - not really surprisingly, because of the
goal of the model is providing a model for a communicating device. They model the real
device viewed from the external - client - DLMS Application, but say nothing about how the
corresponding ( modeled ) real object is implemented.

This abstract model is the key element to ensure independency frob. the real
devicelapplication. In fact, with DLMS, external observers have no more direct access to real
devices: all types of these real appliances - meters, circuit breakers, concentrators, etc... - are
seen as VDEs containing other DLMS objects.

Figure 2. - An external observer does not see real devices but their abstract model.

-
DLMS object types - like object types in general are characterised by their attributes
and with the operations specified on these attributes. Next figure lists the number of
operations per object and summarizes the properties of the DLMS model.

Object Model
1 Interface Model: Does not model the meter itself, I
I only it's external view ! I
Independence of implementation ( on real objects )
Simplicity
- Only five abstract object types:
u Virtual Distribution Equipment (VDE) 2 Operations
2 Data Set 7 Operations ,
8s Task Invocation 5 Operations
m Variable Objects 5 Operations
. m Virtual Application Association (VAA) 1 Operation
- In all only 20 Operations

Figure 3. - DLMS Object Model Properties

I
Somogyi Tibor/Schlumberger Essen. April 2-4.1997 Page 3 of 8
somogyi@montrouge.em.slb.com
12
I
'

-
 adlms
Having abstract objects ensures independency from the real device, the interface object
v
nature of these objects ensures independency of implementation related questions and open
the way to the communications.
\

2.2 DLMS as Application Protocol

The usage of an object model consists of creating instances of object types and
invoking the operations of these different object instances. Communications using of the
DLMS model is just the same - but operations of DLMS objects are invoked remotely. Within
the well-known OSI reference model this kind of remote invoking is expressed as an
Application Protocol - and in order to clearly understand what the term 'Application Protocol'
means we have to briefly recall that OSI model.

This model itself is not a communication protocol, but provides an abstract structure
modelling all communication related functions and serves as the foundation for
communication protocols. It deals with the complexity by logically decomposing the whole
communications system into smaller functional modules, called layers.

In all, seven layers4are specified in the reference model with the Application Layer at
the top and the Physical Layer at the bottom. The figure below shows how communications
take place according to h i s model.

Figure 4. - Communications within the OSI reference model

The two Application Processes - which are outside the model - exchange 'Messages'
using communications functions distributed in the layers, but - and it is one of the key idea of
the layered model - the Application Processes uses ( 'sees' ) directly only the services of the
closest layer ( Application ), which, in turn,uses the services of the next layer and so on down
to the lowest layer which has no more layers but the real world communication medium with
real world signals below.

Without entering into details, OSI divides its seven layers into two groups: lower layers ( Physical(1). Data
Link(2), Network(3), and Transport(4) ) and higher layers ( Session(5), Presentation(6) and Application(7) ) and
says, that these are the lower layers which are responsible for the data delivery, and that are the higher layers
which are dedicated to data processing.

Somogyi TiborISchlumberger &sen, April 2-4, 1997 Page 4 of 8

13
 rdlms
Pa
Each layer "hides" everything below it from the layer's service user. This feature
means, that in specifying Messages and the way the Application Layer processes these
Messages you get:

1. a communications channel independent specification for Application Process

message exchange ( communication channel dependent functions are only in the
lower layers ) ;
2. an interface to a complete communications support, provided by the other layers
( without the other layers being specified at this stage ).

Let's suppose, that one Application Process - the user ( or client ) of the DLMS model
sends messages to the Application Process which contains DLMS Objects, and these
messages are finally the invocations of operations of these DLMS Objects - and we get the
communications view of DLMS. In specifying these messages and the way of handling these
messages at the Application Layer, in terms of the OSI reference model we got an Application
Protocol.

The way of modeling it - following the OSI Application Layer conventions - is to

specify an Application Service ~lement'( ASE ) and the services provided by this ASE in
terms of:

1. supported message formats ( service syntax )

2. dynamic behaviour ( the rules governing the way services are handled ).

Next figure shows the equivalenceof the two - object and communications - models:

DLMS ASE + DLMS AP = VDE

- Independenceon lower layers

DLMS Services =

DLMS Object's Operations +

<

Two Context Management Services (A-l)

- Only 22 DLMS services in all

Figure 5. - Relation between the object- and the communications model

Service syntax for DLMS Services is specified unambiguously by using the IS0
standard Abstract Syntax Notation No.1 (ASN.l). Dynamic behaviour is specified textually
andforby using Time Sequence Diagrams and State Transition Diagrams.

An ASE is a module within the Application Layer which is able to provide services to an Application Process.
Let's note here, that all OSI layers provide services to another layer ( these services are available at the layer's
.Service Access Point or SAP ) except of the Application Layer, which provides services to the Application
Process and has no SAP.

Somogyi TiborISchlumberger Essen.April 2-4. 1997 Page 5 of 8

sornogyi@montmuge.em.slb.com
14
 Client / Sewer type communications model, but
Unconfirmed Service provides multi- and broadcasting facilities
Connection Oriented protocol
Modularity in order to allow simple implemetations
- Mandatory subset of 0bjectsfse~'ces
- Negotiation of the optional part
IEC 1334-4-41 specifies:
- the protocol ( using the standard ASN.l notation )
- the services

Figure 6. - Principal characteristics of the DLMS Application Protocol

i

3. Current Status, towards implementation

lnitihly, DLMS was developed by Electricity de France in association with Landis &
Gyr. The goal was to develop a less complex messaging system than the already standardised
Manufacturing Message Specification ( IS0 9506-1 and 9506-2 ) - and the name DLMS is
coming from the fact, that the first complete communications protocol which includes DLMS
uses the power line carrier technology (PLAN = Power Line Automation Network).

For the same reason, it is the Working Group 9 ( "Distribution automation using
distribution line carrier" ) of the IEC TC57, who discusses and after some years of work
standardizes DLMS - which now is an International Standard ( IEC 133k-441 ). This standard
describes the DLMS Object Model and specifies DLMS as an Application Protocol in terms
of protocol and services.

The same Working Group 9 has other activities with regard to DLMS based
communicitions, concerning other elements of the OSI higher layers ( Transfer syntax,
Association Control Service Element, etc... ) and also concerning PLC communications. A
three-layers or collapsed reference model has been developed in this Working Group, and
until now three PLC communications profiles have been discussed and proposed to be
standardised. I

On the other hand, DLMS gained some interest of different types of utilities and other
standardisation bodies of the meter communications domain. The fact that DLMS fulfills its
original objective makes it very attractive for using it as the basis of all Application Protocol
for any types of meters. Therefore other standardisation groups are working on DLMS related
topics. JEC TC131WG14 is working on DLMS communications profiles for other
communications media ( Twisted Pair, PSTN, etc... ), and CEN TC294 is working on DLMS
based communications for non electricity ( water, gas, heat,... ) meters. A lot of work is in
progress, but the foundation now is ready.

Somogyi Tibor/Schlumberger Essen. April 2-4.1997

somogyi@montrouge.em.slb.com I . Page 60f 8
 Next table gives an idea, what's left to be done:

To specify full communications protocol stack(s):

- Complete Application Layer around DLMS
- Lower Layers
Companion Standards and Specifications
- Registrationof DLMS related entities
Objects
Attributes
- Registrationof communicationsrelated entities
Addresses, addressing rules

With respect to the first point - specify full communications protocol stacks - wetre
already discussed the problem - let' say some words about Companion Standards.

The DLMS model ensures, that a DLMS Client, after k i n g connected to a DLMS
Server, is able to communicate with this DLMS Server: it can get the list of DLMS Objects
within the Server and also it can use any DLMS Objects of the server6. In these terms we can
say that all devices built on the DLMS concept are interoperable.
I

On the other hand the Client somewhere has to kn6w the relation between the used.
-
DLMS model which is the only visible thing of the server and the real objects being-
modeled in DLMS. If the Client ignores this relation, the whole thing worth nothing. For
example imagine that the result of the reading of a DLMS Named Variable gives seven.
Although it seems you get the required information - but if you dont know the meaning ( is it
the current tarifrate or the number of power fails since the last reading ), you cant use this
information, thus it worths nothing for you.

Companion Standards specifies this relation between real objects and objects I object
attributes of the DLMS object model. Full interoperability may be obtained by specifying not
only that you need DLMS, but also that which Companion Standard you require. ,

I
I If the usage of the given object is allowed within the given association.
I

Somogyi Tibor/Schlumberger Essen, April 2-4.1997 Page 7 of 8

somogyi@montrouge.ern.slb.com

16
 4. Conclusions

Although some presentations of multi-media7 metering systems inclqding multi-

vendor meters which are perfectly interoperable I interchangeable thanks to DLMS has been
already done ( MATES'96; DAfDSM'96, etc.. ), DLMS is only at the beginning of its life.
Resolving open technical issues, developing standard communication profiles for other
communications media ( Power Line Carrier, Twisted Pair, etc... ), creating companion
standards for different application fields ( e.g. for other energy distribution equipments than
meters ) or providing complete metering systems - including an indus,trial DLMS client
system - are remaining to be done. But the first steps are already been done, and we are
convinced that the universality, flexibility and the relative simplicity makes it the best
candidate to become THE common language for future communicating metering systems.

7 in terms as well as of using several communications media than several types (electricity-, gas-, water- and heat)
of meters

Somogyi TiborlSchlumberger Essen, April 2-4, 1997 Page 8 of 8

somogyi@montrouge.em.slb.com
17 '