Académique Documents
Professionnel Documents
Culture Documents
w
I
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
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.
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:
'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
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.
\
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.
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.
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:
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.
Next figure shows the equivalenceof the two - object and communications - models:
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.
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.
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
16
4. Conclusions
7 in terms as well as of using several communications media than several types (electricity-, gas-, water- and heat)
of meters