21.06.

12

Implementing DLMS Client and Server Protocols in Meters, IEDs, MRIs and Meter Reading Applicatio

Implementing DLMS Client and Server Protocols in Meters, IEDs, MRIs and Meter Reading Applications An Overview
Vinoo S Warrier, Vice President, Kalkitech
February 22, 2009

Authors
Gopalakrishnan Prasanth

Abstract
This paper presents an overview of the DLMS/COSEM Metering application protocol, its importance in the AMR/AMI scheme of things and provides guidelines on the implementation of DLMS/COSEM clients (in Data collection units and parameterization tools) as well as servers (Meters). This paper explores the protocol as presented in the relevant International standards, the challenges in designing and developing clients and servers and a bulleted sequence of steps required for the protocol modeling and implementation.

I Introduction: Need for standardization

The importance of AMR (Automated Meter Reading) and AMI (Advanced Metering Infrastructure) cannot be overlooked, as evidenced by developments in recent times. AMR and AMI represents two major and sequential steps in the implementation of transparent metering and billing, detecting and preventing fraud/losses, providing for business intelligence to drive decision-making at the highest levels regarding energy capacity and demand requirements, understanding and controlling peak demand cycles, optimizing dispatch from critical and expensive energy resources and a host of requirements in the overall energy generation, transmission and distribution functions. One of the major factors that impact the success of such AMR/AMI designs is the communication protocol that is utilized for collecting consumption and demand data from the individual users of energy. Traditional systems in India have relied heavily upon the meter manufacturers to provide a comprehensive and complete solution for AMR, from providing meters, software for reading the data from the meters and even the base computer system (The central data collection system) as parts of one complete whole entity for AMR. The consequence of such a system was to push the meter manufacturers to develop their own proprietary communication protocols. The design of such protocols would be driven by current project requirements and overall project costs and budgets that would not necessarily put sufficient emphasis on the scalability of the protocol. Needless to say, the interoperability of the protocol was never in the scheme of things until very recently. The need for international standards is an understood concept and a foregone conclusion in many aspects of the energy automation sector, from SCADA/DCS systems to Substation Automation, Protection, Monitoring and Control. However the metering industry in India is relatively new to the concept and the need for such solutions. An international standard brings to the table many benefits. One such is the fact that such standards are developed by a body of experts from diverse locations, frequently populated by experts from countries and systems that are highly advanced and futuristic. Naturally a proprietary protocol designed by a group of people working for one specific company cannot compare with a product from such a body of experts with their collective experience. DLMS/COSEM is such an international standard, maintained by the DLMS User Association and dual-standardized under the DLMS Colored books as well as the IEC-62056 protocol standards. The DLMS/UA consist of about 130
gopalakrishnanprasanth.wordpress.com//implementing-dlms-client-and-server-3bk0x32fl4sfh-15/ 1/7

21.06.12

Implementing DLMS Client and Server Protocols in Meters, IEDs, MRIs and Meter Reading Applicatio

members at the last count and works closely with the following international technical committees - IEC TC13 WG14 Data exchange for meter reading, tariff and load control CEN TC294 WG2 Communication Systems for and Remote Reading of Meters IEC TC57 WG09 Distribution automation using DLC systems The DLMS/COSEM standards are maintained in the DLMS Colored books which have mirror specifications in the IEC as in the following table Description COSEM meter object model and the object identification system Architecture and protocols to transport the model DLMS- IEC UA Blue Book Green Book IEC-6205661 IEC62056-62 IEC-6205653 IEC-6205646 IEC-6205642 IEC-6205647 Conformance testing process Glossary of DLMS/COSEM terms Yellow Book White Book Table1: DLMS/COSEM Standards -

II The DLMS/COSEM Protocol

The DLMS/COSEM protocol provides the following broad specifications as below (using the IEC nomenclature for clarity) IEC-62056-61 : Object Identification system, popularly known as OBIS codes provide an unambiguous and unique code to identify each quantity in the metering domain. An OBIS code consists of a six-number sequence, each number in the sequence represented by a number between 0 and 255 and referred to as value groups A through F. A complete OBIS code thus consists of a sequence A.B.C.D.E.F that uniquely identifies a specific metered quantity. For example, the obis code 1.1.1.8.2.27 represents the active energy export under tariff 2 for the 3rd last billing period (when the current billing period is numbered as 30) IEC-62056-62 : Interface Classes represent the classes or blueprints for objects that display similar proerties and methods. The specification defines a large number of Interface Classes to define different kinds of information. For example, instantaneous quantities like the billing period counter could be modelled by a Data class (IC:1), whereas quantities like Energy which require both the value information as well as units and scaling factor could be modelled by a Register object (IC:3). Quantities that require the timestamp of the value also, can be modelled by an Extended Register (IC:4) and Demand values that need to provide the current and last average value can be modelled by a Demand register (IC:5). Historic values like load profiles can be modelled by a Profile generic (IC:7) object. In addition to classes representing the metered data, there are a large number of classes for abstract (media-independent) information like the meter clock, tariffication handling, communication profiles etc. There may be many instances (objects) of a specific class,
gopalakrishnanprasanth.wordpress.com//implementing-dlms-client-and-server-3bk0x32fl4sfh-15/ 2/7

21.06.12

Implementing DLMS Client and Server Protocols in Meters, IEDs, MRIs and Meter Reading Applicatio

(for example Register) in a meters data list. Each of these objects is of the same class but has a different OBIS code that uniquely identifies it. IEC-62056-53 : The COSEM standard specifies the application layer protocol for exchanging meter information modelled as objects of interface classes (Part 62) and named by OBIS codes (Part 61). The protocol provides the following features Two methods of referencing data, called logical-name and short-name referencing Ability to negotiate parameters during association establishment. Ability to download the meter object list, inlcuding the access privileges for each objects attributes and methods Abillity to synchronize the function set between the client and the server (called the conformance block) Basic Request-Response Services in both SN and LN referencing Variants of each service (for example the Get service) that provide services for selective access, block transfer etc. And so on

IEC-62056-46 : The HDLC Data link protocol provides for transporting COSEM requests and responses across a serial link (direct serial access or extended by PSTN/GSM or radio modems etc.) and provides for data framing, data integrity checks, flow control, segmentation and re-assembly etc. IEC-62056-47 : The TCPUDP wrapper specifications provides an alternative transport for COSEM requests and response over a TCPIP or UDPIP network

III Server Implementation in Meters: Data Modelling

The primary task in implementing a DLMS/COSEM server protocol driver in a meter is the modeling of the meter data values into DLMS objects. There are two aspects to modeling the data. The first is to identify the appropriate OBIS code that identifies the specific quantity and the second is to choose the appropriate Interface Class that represents that quantity. It is necessary to perform the modeling strictly in the sequence as specified above, since the OBIS codes are usually directly associated with an Interface Class or with a set of Interface Classes, thus restricting the choice of the class to be used to a finite set. This is not a restriction per se since the standard OBIS code document[1] selects the best possible choices already. An example model of a very simple energy meter is provided in Table 2 below Sn 1 2 3 4 5 6 7 8 9 10 Meter data Active Energy, Total Active energy, phs A, Tariff 1, Current Billing period Active Energy, phs B, Tariff 2, Current billing period Active Energy, phs C, Tariff 1, Last billing period Instantaneous L1 Voltage Instantaneous L3 Current Billing Period Counter Billing data profile Clock Tariffication Calendar with timeswitches in seasons, weeks and daily profiles 11 Logical Device Name 0.0.42.0.0.255 1
3/7

OBIS Code 1.1.1.8.0.255 1.1.21.8.2.255 1.1.41.8.2.255 1.1.61.8.1.16 1.1.32.7.0.255 1.1.71.7.0.255 1.1.0.1.0.255 0.0.1.0.0.255 0.0.13.0.0.255

IC 3 3 3 3 3 3 1 8 20

1.1.98.1.255.255 7

gopalakrishnanprasanth.wordpress.com//implementing-dlms-client-and-server-3bk0x32fl4sfh-15/

21.06.12

Implementing DLMS Client and Server Protocols in Meters, IEDs, MRIs and Meter Reading Applicatio

12

SAP assignment

0.0.41.0.0.255

17

Table 2: Sample meter model for a simple case The next step is to model the associations supported by the Meter. DLMS/COSEM provides the option of specifying several different associations identified by the addresses of the client and server logical devices participating in the association. For example there is a mandatory association called the public client association that is established between a public client with address 16 (called the client SAP or service access point) and the management logical device with address 1 (the server SAP). Each association can be designed to provide access to a specific subset of the meter data with different access privileges to the attributes and methods of each data object. Designers are free to choose additional associations for each kind of client that will interact with the meter. Examples are meter-reader association, Factorysettings association, Parameterization-association etc. An example associations model of the hypothetical meter data model presented in Table 2 is provided below in Table 3. This model designs for 3 associations for the sample meter. Sno 1 Meter data Active Energy, Total Public Client No Meter Read Factory Read Write 2 Active energy, phs A, Tariff 1, Current Billing period 3 Active Energy, phs B, Tariff 2, Current billing period 4 Active Energy, phs C, Tariff 1, Last billing period 5 Instantaneous L1 Voltage 6 Instantaneous L3 Current 7 Billing Period Counter No Read Write 8 Billing data profile No Read No No No No Read Write Read Write Read Write Read Write 9 Clock No No Read Write 10 Tariffication Calendar with time-switches in seasons, weeks and daily profiles 11 Logical Device Name Read Read Read Write No No Read Write No No Read Write No No Read Write No No Read Write

Reader Settings

12

SAP assignment

Read

Read

Read Write

gopalakrishnanprasanth.wordpress.com//implementing-dlms-client-and-server-3bk0x32fl4sfh-15/

4/7

21.06.12

Implementing DLMS Client and Server Protocols in Meters, IEDs, MRIs and Meter Reading Applicatio

Table3: Associations model for the sample meter The SAPs participating in the three associations described above are as follows

1. Public Client (Client 010, Server 001) 2. Meter Reader Client (Client 015, Server 001) 3. Factory Setting Client (Client 016, Server 002)

The model above represents that the sample meter has two Logical devices, the Management Logical device with server SAP 001 and an additional logical device with server SAP 002. The meter supports three associations between three distinct clients and these two logical devices in the server. Thus logical devices and associations are used to classify the meter data into distinct subsets for the purposes of different clients that will interact with the meter. A client driver that establishes an association to the meter using the public client address 010 will only see two objects, the SAP Assignment object and the Logical Device Name object when it downloads the associations object list. Further the client will be permitted to only read the data in these two objects since the association programmed in the meter does not give write access. The designer at this stage can also specify the security mechanisms related to authentication of the client and security of the transactions. Authentication DLMS/COSEM provides for three levels of authentication

1. Lowest level: No authentication 2. Low level: Password based authentication 3. High level: 4 pass authentication where the client and server exchange challenges and then respond with a
processed key based on the challenge data

For the above association model, the public client association could use lowest level, the Meter reader association could use low level and the factory settings association could use high level authentication. Security DLMS/COSEM provides for two kinds of application contexts, ciphered (encrypted) and without ciphering under both Logical name as well as Short name referencing. The designer at this stage can decide on the appropriate security mechanism for each association. Selective Access DLMS/COSEM provides options to implement selective access to specific attributes of specific objects (for example the buffer of a load profile or the object list of a meter). The selective access is available in different mechanisms, for example selective access by range or by entry for profile buffers. Designers are encouraged to implement and take advantage of this feature to provide options to the AMR system to optimize its communication bandwidths and performance.

IV Client Implementation in Meter reading and parameterization tools

Client implementations of DLMS/COSEM should adhere to the following guidelines.

1. DLMS/COSEM specifies the Logical Name referencing method as the mechanism of choice for presentation at the
gopalakrishnanprasanth.wordpress.com//implementing-dlms-client-and-server-3bk0x32fl4sfh-15/ 5/7

21.06.12

Implementing DLMS Client and Server Protocols in Meters, IEDs, MRIs and Meter Reading Applicatio

clients user layer or the application interface. This means that the client implementation will present meter data using LN services and representation, irrespective of whether the connected meter utilizes LN or SN referencing. This also means that the client implementation must provide a SN Mapper service to translate between the two referencing mechanisms when dealing with SN meters.

2. Clients cannot have the luxury of selecting specific options when it comes to features support like conformance
block functions, authentication mechanisms, application contexts etc unlike servers which can opt for a fixed subset of the features. The reason for this is that a client connected to a data collection center may have to deal with a large number of meters from different manufacturers which have different feature sets. The client will need to implement a vast majority of the selectable options in order to be able to communicate with the entire range of meter implementations

3. Client implementations must especially pay heed to the numerous negotiable features in DLMS, namely the HDLC
parameter negotiations where different meters may support different window sizes and information field lengths depending upon the meters available resources, COSEM services named in the conformance block, ASU sizes etc.

4. Since DLMS is a self-descriptive protocol, it allows clients to download the object list from meters, including access
privileges. Clients should be designed to take advantage of this feature and provide user controls to configure the AMR network directly by connecting to meters. This is in addition to the usual practice of providing user-entry configuration screens to configure the meters into the system

V Protocol Stack Implementation

The protocol stack implementation process requires decisions on the services supported (related to the conformance block of the meter), which specifies the application level COSEM services that the meter is required to support, as well as lower layer parameters like the window sizes and information field lengths that HDLC can support, for example. The implementation process is a straight-forward implementation of the application, data link and physical layers per the standard specifications. A detailed description of the software implementation of the stack is beyond the scope of this paper.

VI Conclusion
This paper discusses the features of the DLMS/COSEM metering protocol and provides a sequence of steps leading to the modelling and implementation of the protocol in meters and meter-reading tools. It throws light on the numerous flexible features of the protocol that make it a suitable candidate for AMR/AMI implementations.

VII References
1. 2.
DLMS-UA List of standard OBIS codes downloadable from http://www.dlms.com/documentation/listofstandardobiscodesandmaintenanceproces/index.html. DLMS Colored Books http://www.dlms.com

IX Biography
Vinoo S Warrier completed his Engineering degree in Production Engineering and Management from REC Calicut, Calicut University, India in 1995. He worked with MICO-Bosch in Bangalore India for a period of three years before joining KalkiTech in 1999 and has been with KalkiTech since then in various capacities. He currently serves as the Vertical head for the Communication Solutions vertical and oversees the Product Engineering and Communication Products Business units of Kalkitech. His major interest areas are control and automation, embedded systems and communication protocols.
gopalakrishnanprasanth.wordpress.com//implementing-dlms-client-and-server-3bk0x32fl4sfh-15/ 6/7

21.06.12

Implementing DLMS Client and Server Protocols in Meters, IEDs, MRIs and Meter Reading Applicatio

gopalakrishnanprasanth.wordpress.com//implementing-dlms-client-and-server-3bk0x32fl4sfh-15/

7/7