Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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.
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 -
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
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.
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
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