База знаний

Режим чтения файла

Questions and answers - FAQ

A) General questions

B) Questions on the DLMS/COSEM specification

C) Questions on Conformance Testing

A) General questions

What is DLMS?

DLMS stands for Distribution Line Message Specification. It is an application layer specification, independent of the lower layers and thus of the communication channel, designed to support messaging to and from (energy) distribution devices in a computerintegrated environment. It is an international standards established by IEC TC 57 and published as IEC 61334-4-41.

The concept was driven forward later to become Device Language Message Specification with the objective to provide an interoperable environment for structured modelling and meter data exchange. Applications like remote meter reading, remote control and value added services for metering any kind of energy, like electricity, water, gas or heat are supported.

What is COSEM?

COSEM stands for COmpanion Specification for Energy Metering. It is an interface model of communicating energy metering equipment, providing a view of the functionality available through the communication interfaces. The modelling uses an object-oriented approach.

COSEM models physical metering equipment as a set of logical devices. Each and every logical device has a world-wide unique identifier called the logical device name. Information contained in each logical device is modelled by interface objects. Access to the interface objects within a logical device is modelled by association objects. An association object provides information about the resources available in the logical device in a given context, depending on the access rights.

The interface objects are specific to the metering domain, using well known concepts like register, demand register, profile, clock, schedule etc. There are also special objects controlling access (the association objects) and configurings the communication channels.

The information that is held by an interface object is organised in attributes. Attributesrepresent the characteristics of an object by means of attribute values. An object may also offer a number of methods to either examine or modify the values of the attributes. Object that share common characteristics (same attributes and methods) make up an interface class identified by the class_id and version. On the other hand, interface objects are instances of interface classes.

The first attribute of any object is the logical name, which is one part of the identification of the object. The logical name, together with the class_id and the version unambiguously identifies the meaning of the information presented by any interface object, in a manufacturer independent way.

The COSEM model allows identifying, retrieving and interpreting the information held in any meter in a manufacturer independent, controlled and secure way.

The attributes and methods of COSEM interface objects can be accessed using xDLMS application layer protocol services, turning the information into series of bytes and transporting these over the protocol layers between peer applications.

The DLMS UA has also specified a protocol stack, based on the Open Systems Interconnection (OSI) model, for transporting the model over serial interfaces, like optical ports, electrical current loop interfaces, PSTN and GSM modems.

What is the DLMS User Association?

The DLMS Use Association is a non-profit organisation, located in Geneva, Switzerland. Its mission is to develop, promote and maintain the DLMS/COSEM specification. It provides an information exchange forum for users, manufacturers and system providers, test houses and standardisation bodies. It also provides a conformance testing and certification scheme for metering equipment implementing the specification. The DLMS UA is formally liased with IEC TC 13 WG 14.

What are the benefits of DLMS/COSEM?

The main benefit of DLMS/COSEM is that it brings interoperability.

Broadly speaking, interoperability means that any meter data management system can talk to any meter, independently of the manufacturer, the type, the energy type measured and the communication media. This also assumes, that on both sides a compatible set of features are correctly implemented.

On the interface model level, the essential elements assuring interoperability are:

On the COSEM application layer level, interoperability is ensured by the possibility to negotiate the protocol context, the authentication mechanism and the service set available for accessing attributes and methods.

The availability of conformance testing, a first in metering protocols, greatly improves the probability of interoperability by verifying the correctness of the implementation on the interface and the protocol stack levels.

How is DLMS/COSEM different from other standards for meter data exchange?

The most commonly used standard for meter data exchange is the FLAG protocol, standardised for the purposes of electricity metering as IEC 61107 by IEC TC 13. Other protocols widely used are:

While it is not the objective here to give a detailed comparison between these protocols, the main points, rendering DLM/COSEM particularly suitable to meet the needs of the liberalised energy markets are summarised below:

This unique combination of features, not available in any other metering protocols known presently, supports the business processes of the various stakeholders on the liberalised markets, support innovation and competition, and drastically reduce system life cycle costs.s

Where is DLMS/COSEM used?

DLMS/COSEM is used in metering systems for electricity, gas, water and heat. Strong and growing interest from all continents provide a positive feedback on the achievement of the objectives set by the DLMS UA. Some countries have already included DLMS/COSEM in their national regulations. Others are considering it.

Who provides DLMS/COSEM metering systems?

Status end 2005 Implementations

Implementations – general

Implementations – meters

Some system implementations

How can I join the DLMS User Association?

The DLMS User Association is open to any organisation or individual, manufacturers, utilities, legal bodies, consultants, test houses etc. and their associations sharing the objectives of the DLMS UA and interested in interoperable systems for meter data exchange.

Joining the DLMS User Association is very easy via Internet:

The Management Committee of the DLMS UA has to approve the application. When it is acknowledged the invoice is sent. Membership starts as soon as the payment is booked.

Is DLMS/COSEM an open specification?

The DLMS/COSEM specification is open and it is available without discrimination to anybody.

The DLMS/COSEM specification has been developed by the DLMS UA. It is included in the “Blue Book” and the “Green Book” of the DLMS UA. These books are available to all DLMS UA members.

The specification has been offered for international standardisation to IEC TC 13 for the purposes of electricity metering and to CEN TC 294 for the purposes of utility metering other then electric ity. The IEC 62056 series of standards – parts 6-42, 6-46, 6-53, 6-61 and 6-62 have been published in early 2002. The EN 13757-1 standard is expected by Q4 of 2002.

In addition, the DLMS UA has developed and maintains a conformance testing and certification scheme, providing equal terms and conditions for testing implementations. This is described in the “Yellow Book” and it is also available for DLMS UA members.

What communication media are supported?

At this time the protocol stack defined in the Green book allows to use DLMS/COSEM through direct connection via an optical or electrical port, via switched or leased telephone lines and over the GSM network.

As the COSEM application layer is completely separated from the lower layers, it is easy to define other protocol stacks, based on OSI or not, to support other communication media. This will be done as market requirements justify.

Can I use DLMS/COSEM over the Internet?

The use of DLMS/COSEM over the Internet is not yet defined. However, in order to benefit from the advantages of this ubiquitous technology, the subject is under consideration by the DLMS UA and feasibility studies have been started.

What is xDLMS?

xDLMS is an extension to the DLMS standard.

The main objective of the COSEM approach is to provide a business domain oriented interface object model for metering devices and systems while keeping backward compatibility to the existing DLMS standard. To meet these objectives, COSEM includes an evolution of DLMS. Remaining fully compliant to the DLMS standard, COSEM provides a more metering specific view of the meter through the COSEM interface objects.

xDLMS is the application layer service element providing access to the COSEM objects. It contains a few new services, mainly to support LN referencing, and defines additional data types. It defines new conformance block. The current DLMS version of xDLMS is 6.

B) Questions on the DLMS/COSEM specification

Is DLMS/COSEM suitable for simple meters?

While DLMS/COSEM is able to support a very rich feature set, it is also suitable for simple metering equipment.

This is possible because there are only a few mandatory elements. So very simple devices can be modelled – or when taking more options, very complex ones as well.

On the model level, the only mandatory element is the management logical device, which may be the only one. This must contain a SAP assignment object holding the SAP-s of all logical devices. Each logical device must have an object holding the logical device name, and a current association object, so that the list of objects available can be retrieved. For simple devices with small memory resources, pre-established associations can be defined. The management logical device must support an association with a public client, allowing the retrieval of the structure of an unknown meter. Everything else is left to the choice of the implementer.

Short name or logical name referencing?

Any piece of information modelled by COSEM can be accessed as an attribute or method of a certain COSEM interface object. To access an attribute or method, it has to be referenced. In the metering equipment (server) the COSEM application layer provides two mechanisms to access the attributes. One is called short name (SN) referencing and the other is called logical name (LN) referencing. The data collection system (client) application layer always uses LN referencing.

When SN referencing is used, the attributes and methods of each interface object are mapped to DLMS named variables. This is done during the design of the meter. Each named variable is identified with a short name, which is a 16 bit unsigned integer. Attribute 1, the logical name of the object is mapped to a DLMS named variable identified by a base name. Except in the case of a few special objects, there are no general rules defined for assigning base names. All other attributes and methods of the object are then also mapped to DLMS named variables. The offsets between the base name and the short name identifying the other attributes and methods are defined in the definition of each interface class. The actual values of the short names thus depend on the number and kind of objects instantiated and the mapping strategy used. The base names allocated in the metering equipment can be retrieved by reading the object_list attribute of the SN Association object. When SN referencing is used, the DLMS named variables are accessed by the standard DLMS READ and WRITE services.

When LN referencing is used, attributes and methods are accessed via the logical name of the object, specifying the index(es) of the attribute(s) and/or the method(s). Logical names are defined by OBIS. When LN referencing is used, the attributes and methods are accessed by the xDLMS GET/SET and ACTION services.

As the data collection system (client) application layer always uses LN referencing, the LN service requests are mapped to SN service requests by the Short Name Mapper service element of the application layer.

SN referencing has been inherited from the original DLMS standard. LN referencing is the result of the evolution of the specification.

Which is the better? The answer is none of them. Simply put, SN referencing is more suitable for simple devices and LN referencing for complex devices. The use of short names limits the possible number of objects within a logical device. Depending on the complexity, an interface object occupies a range of 8 (Data) to 136 (Clock) short names, starting with the base name. The whole range available is 8192. Therefore, the maximum number of objects depends on the type (complexity) of objects used and the strategy of allocating base names. On the other hand, APDU-s for SN referencing are shorter than APDU-s for LN referencing. With LN referencing, the limit is only set by the possible OBIS names (in principle 255**6). There are a few advanced features available only with LN referencing. However, this will make the software of the meter slightly more complex.

Finally, it is important to note, that the referencing style and the corresponding service set is negotiated at application association establishment and thus interoperability is fully preserved. There are known both complex and simple metering equipment using either SN or LN referencing, end even meters using both referencing styles.

What is the purpose of the upper HDLC address?

DLMS/COSEM is based on the Client/Server paradigm, where the data collection system acts as the Client and the metering equipment acts the Server, providing services to the Client. The Server is modelled as a physical device containing one or more logical devices, each logical device supporting one or more application associations with the Client(s) and two or more COSEM objects.

In the three-layer, connection oriented, HDLC based communication protocol, addressing is performed by the MAC layer. The lower HDLC address is used for addressing the physical device and the upper HDLC address is used for addressing the various logical devices within the same physical device. Application associations are established between a Client and a Logical Device in the Server. The associations are identified by the pair of HDLC addresses (Client HDLC address – Server lower HDLC/upper HDLC address). The HDLC based data link layer supports the lower HDLC/upper HDLC address structure by using the extended addressing mechanism provided by the HDLC standard ISO/IEC 13239. It is to be noted, that for the purposes of DLMS/COSEM a new frame format type 3, containing both the source and the destination addresses have been added to ISO/IEC 13239.

In a full OSI protocol stack the “Transport Services Access Point” has the same role as the upper HDLC address in the three-layer, connection oriented, HDLC based protocol stack used with COSEM. TSAP is a point in the transport layer of an OSI based product that can be accessed for addressing purposes. This address can be used in addition to the main network addressing.

Using a non-OSI example, the role of the upper HDLC address is similar to the “port number”. A computer, a single physical device is running various applications like web, mail, ftp. The computer can be accessed using its IP address, and the various applications – which are similar to DLMS/COSEM logical devices - can be accessed using their port numbers. Many people know that the assigned port number for World Wide Web HTTP is 80 and the standard port for Simple Mail Transfer Protocol is 25.

What is the purpose of the management logical device?

Simply speaking, the management logical device is the logical device, which must always be present in the physical device, and for which the upper HDLC address 0x01 is reserved.

Today it is very common that a single physical metering equipment handles multiple metering tasks. A simple example is a heat meter with a pulse input for a water-metering device. A more complex example would be a concentrator handling data for a number of meters.

According to the DLMS/COSEM meter model, each set of metering data is handled by a logical device implemented in a physical device.

The question is now how to know how many logical devices are inside the physical device? We need a ‘porter’ or ‘concierge’ to ask. This is the task of the management logical device.

The management logical device must have a SAP assignment object, which contains the list of all logical devices and their SAP addresses within the physical device. The management logical device must support an application association to a public client, with the lowest security level. The client address 0x10 is reserved for the public client. In case of LN referencing, the SAP assignment object has a predefined logical name. In case of SN referencing, the base_name of the SAP assignment is pre-defined as 0xFC00.

As the only mandatory logical device is the management logical device, it is possible that this is the only logical device in the meter and it contains the metering data as well. However, this would be a hac k violating the spirit of COSEM. A much better approach would be to ”mirror” the management logical device on another upper HDLC address as the metering logical device. The overhead of such a solution is very small.

What is the purpose of the public client?

The purpose of the public client is to support the retrieval of the structure of an unknown meter.

The Client address 0x10 is reserved for the public client. The management logical device, having a reserved upper HDLC address 0x01 must support an application association to this public client with lowest security. The SAP addresses of all logical devices can be found by reading the SAP assignment object. The list of objects available (in case of SN referencing, with their base names) and the access rights to their attributes and methods can be retrieved by reading the object_list attribute of the application association.

The Association objects, what are they?

In DLMS/COSEM, the association objects play a role of a ‘gatekeeper’, controlling access to the information in the meter and providing information on what is available.

As there are two referencing methods, there are also two types of association objects, one for Short Name and one for Logical Name referencing.

Although they perform the same task, the Association SN and the Association LN objects are slightly different.

The logical name of the current association object is 0.0.40.0.0.255. In case of SN referencing, the base_name of the current association object is 0xFA00.

Several instances of association objects are possible. For their identification, the value group E is used. At a time, there is only one association in a logical device, which is current. This is to avoid the complexity of safe ‘multi-user’ data handling in a meter. On the other hand, nothing forbids having access at the same time to multiple logical devices, if this is supported by the lower layers.

Both the Association LN and SN objects have an object_list attribute, providing the list of interface objects ‘visible’ in the given association. In case of LN referencing, the object_list provides the class_id, the version, the logical_name and the access rights to the attributes and methods for each object. In case of SN referencing, the object_list provides the base_name, the class -id, the version and the logical_name of each object. To retrieve the access rights, the get_attributes&methods method can be used. Default access right may be used (e.g. read only to attributes, no access to methods).

The Association LN object also holds the information about the associated partners (client - logical device), the application context, the xDLMS context, the authentication mechanism, the LLS secret (when this mechanism is used) and the association status.

The methods of the Association LN object support High Level Security Authentication and allow adding objects to the object_list or to remove them.

The methods of the Association SN object support reading objects by their logical name, to retrieve access rights and they also support the High Level Security Authentication process.

How to connect to a logical device?

There are two different situations; the first being, that the data collection system (client) knows the structure of the metering device (server) and the second that the device is unknown to the client.

The client must know in advance the physical device address, which is the lower MAC address of the device if it is connected to a LAN, e.g. when multi-drop is used. In case of modem connection, the telephone number and the modem connection parameters need to be known. If security mechanisms are used, the password or the ‘secret’ needs to be known as well.

When the structure of the metering device is known, the process is the following.

  1. Connect the physical layer. Optionally, negotiate the protocol stack.

  2. Connect the data link layer using the known lower HDLC address and the known upper HDLC address of the selected logical device within the physical device. Optionally, negotiate data link layer parameters.

  3. Establish the application association, negotiate the application context (SN or LN referencing), the xDLMS context and perform authentication, using the known password or HLS secret.

  4. Access the selected attributes and methods, using the appropriate service set. This is GET/SET/ACTION when using LN referencing and READ/WRITE when using SN referencing.

  5. Terminate the data link layer connection – this will release the application association as well – and establish another association or terminate the physical connection.

The actions to perform when the structure of the metering device is not known are more complicated. They will be as follows:

  1. Connect the physical layer. Optionally, negotiate the protocol stack.

  2. Connect the data link layer using the reserved address of the public client (0x10), the lower HDLC address of the physi cal device and the upper HDLC address of the management logical device (0x01). Optionally, negotiate data link layer parameters.

  3. Establish the application association, negotiate the application context (SN or LN referencing) and the xDLMS context. No authentication is required.

  4. Access the SAP assignment object (in case of LN referencing, logical name 0.0.41.0.0.255), in case of SN referencing 0xFC00) to retrieve the list of logical devices and their SAP-s. The SAP_assignment_list attribute delivers the SAP of each logical device with its logical_device_name. When short name referencing is used, the base_name of the COSEM logical device name object is 0xFD00.

  5. Disconnect the data link layer and connect again using the address of the appropriate client address and the upper HDLC address of the logical device selected.

  6. Establish the application association, negotiate the application context (SN or LN referencing), the xDLMS context and perform authentication (password must or HLS secret must be known).

  7. Retrieve the object-list from the association object with access rights to attributes and methods.

  8. Browse through the list and find the objects of interest in the logical device.

  9. Access the selected attributes and methods using the appropriate service set. This is GET/SET/ACTION when using LN referencing and READ/WRITE when using SN referencing.

  10. Terminate the data link layer connection – this will release the application association as well – and establish another association or terminate the physical connection.

The physical device may support installation of the metering device by calling in to the data collection system when it is installed.

What is the logical device name?

The logical_device_name is used for a world-wide unique identification of each logical device.

It is an octet -string up to 16 octets. The first three octets uniquely identify the manufacturer of the device. It is assigned by the DLMS UA in co-operation with the FLAG Association. The manufacturer is responsible for guaranteeing the uniqueness of the octets that follow (up to 13 octets). The logical device name is held by the SAP assignment object or a COSEM logical device name object - a data or register object with the logical name 0.0.42.0.0.255. When short name referencing is used, the base_name of the COSEM logical device name object is 0xFD00.

Security features, what is supported by DLMS/COSEM?

DLMS/COSEM brings enhanced security features by providing a controlled access to the data stored in the meter using different levels of authentication.

On monopoly markets, only the utility had to have ac cess to the data in the meter and it was entitled to see all data. On deregulated markets, various parties need access to the information and normally they have rights to access a subset of data only. This market need is supported by controlling the access with the association objects. The association object provides different views of the information to the different clients, under the appropriate authentication mechanism.

The association may be established with lowest level security, low level security or high level security. Lowest level security is mainly used to support the retrieval of the structure of a meter unknown for the data collection system. Low level security (LLS) provide a password based authentication of the client. It is typically used when the communication channel offers adequate security to avoid eavesdropping and message (password) replay.

High level security (HLS) is a four-pass authentication, using cryptographic algorithm and secret cryptographic keys. With HLS, both the Client and the Server authenticates itself. This authentication mechanism is used in the case when the communication channel does not offer adequate security to avoid eavesdropping and message (password) replay. The DLMS/COSEM specification does not specify details of the HLS mechanism.

In addition, encryption can be used. This is provided by the xDLMS service element of the application layer.

OBIS names, what are they?

OBIS stands for Object Identification System. OBIS provides standard identifiers for all data within the metering equipment, both measurement values and abstract values. OBIS names are used for the identification of COSEM objects and also for identification of the data displayed on the meter and transmitted through the communication line to the data collection system.

The need for standard identification systems has been identified with the advent of complex multifunctional meters , when a great number of data had to be read and transmitted. Some countries have created their own standards, but most manufacturers used proprietary systems. One of the widely recognised systems was the Energy Data Identification System (EDIS) defined in Germany. This system has been picked as the basis of OBIS.

OBIS uses six value groups in a hierarchical structure. Value group A identifies the energy type measured. A=0 identifies abstract codes. Value group A has reserved space for future extensions. Value group B identifies the measuring channels. Value group C identifies the physical quantity measured, while value group D identifies the processing methods and country specific codes. Value group E is used for identifying rates or can be used for further classification. Value group F is used for identifying historical values or can be used for further classification. Groups B to D have code space for manufacturer specific identifiers.

Standard codes for electricity, cold water, hot water, gas, heating and cooling are defined in the DLMS UA Blue book. A list of full standard OBIS codes, valid combinations of standard values in each group, is maintained by the DLMS UA. The list is available on the DLMS UA web-site and it is regularly maintained. The DLMS/COSEM conformance tool checks the logical name of each object found in the meter under test based on this table.

Manufacturer specific objects, are they possible?

DLMS/COSEM provides a rich set of standard objects to support a wide functionality of metering equipment. However, in order to support innovation, manufacturer specific objects can be defined and used. These will be identified by manufacturer specific OBIS codes. An OBIS code is manufacturer specific, if any of the value groups B to D has a value between 128 and 254.

In order to maintain interoperability, manufacturer specific objects should not be used for a purpose for which a standardised object is defined. In order to allow interpretation of manufacturer specific objects by the data collection system, extra information is needed.

It is to be noted that manufacturer specific objects shall be still instances of standard interface classes and the type of the attributes is tested by the CTT. On the other hand, manufacturer specific attributes and methods are allowed.

What elements of the specification need to be registered?

There are a number of elements in the specification, which need to be registered.

These are the following:

The registration services are provided by the DLMS UA. The lists of registered elements are available on the web-site of the DLMS UA, under “Documentation”.

How can a meter report an event?

Events in the server may occur any time and they have to be reported to the client. This is always done by the server management logical device (address 0x01) to the client management application process (address 0x01).

In case of using the three-layer, connection-oriented, HDLC based protocol stack, the process is the following.

The lower layers may not be able to send the message out, e.g. the physical connection may not exist, or if the data link layer does not have the token.

If the physical connection does not exist, it is initiated by the server. Once the physical connection - including the identification service - is done, the EventNotification.request APDU is sent to the data link layer, where it is pending, waiting for a send opportunity.

The server, detecting the event may be in a multi-drop configuration. When the client receives a call, it has to find out, which server on the multi-drop was calling. Therefore, it builds a DL connection, using a special lower HDLC address, the CALLING Physical address (0x7E resp. 0x3FFE) and as upper HDLC address, the management logical device address. Only the physical device calling in will respond and build the data link layer connection.

If the server has no right to talk, the client has to trigger sending out the pending PDU. This is done by sending an empty UI frame to the server with the P/F bit set to 1, giving the permission to the server to send.

The pending PDU is sent in a UI frame, and upon its reception, it is passed on to the Client management application process. The Client AP, depending on the content of the EventNotification, may decide what to do next.

With lower layers other than HDLC, the authorisation to send out the pending EventNotification PDU may be different.

C) Questions on Conformance Testing

Conformance testing, how can I get my implementation tested?

The DLMS UA provides a conformance testing process. The main elements are:

The process is based on self-testing, using the test tool developed by the DLMS UA.

The CTT can be purchased by any member of the DLMS UA from Euro DCS http://www.eurodcs.de at the commercial conditions agreed by the DLMS UA.

For more information, check out the conformance testing pages of this website.

Conformance test reports, how can I obtain?

Conformance test reports are filed by the DLMS UA, but they are not published. Copies should be available from the vendor.

How can I get my implementation registered as DLMS/COSEM compliant?

To register your implementation as DLMS/COSEM compliant, send in the conformance test report to the DLMS UA. The DLMS UA will verify the contents and the authenticity of the test report. If everything is ok, it will list the implementation identified by the test report on the DLMS UA conformance testing web-site and will issue a certificate.

How the conformance test tool is maintained?

The DLMS UA regularly maintains the conformance test specifications and the conformance test tool to allow testing new features and to increase the depth of testing. The process is described on the DLMS UA conformance testing web-site.

How should products be labelled after passing the conformance test?

Upon acceptance of the test report, the DLMS UA recommends that the manufacturer displays the “DLMS/COSEM compliant” mark on its product and product literature. The “DLMS/COSEM compliant mark can be found on the DLMS UA conformance testing website.

If I make enhancements to my product after it has passed conformance test, do I need to re -test my product?

The DLMS/COSEM test certificate is valid for the product identified in the test certificate. The features of the product having passed the test are listed in the PICS and PIXIT files, which are part of the test report. The list of objects can be identified by browsing through the COSEM object list test part of the test report. If during a product enhancement new features are added which were not tested earlier, the product must be re-tested so that compliance can be claimed.

Product configurations, do they need to be re -tested?

It is recommended that conformance testing is made on a few different configurations, characteristic for the implementation. It is recommended also that the IUT is configured for the tests in such a way, that all features implemented and available in any valid configuration are tested. It is also the common interest of the vendor and the purchaser. The purchaser may request any time testing any configuration used.

Note: This document answers some Frequently Asked Questions concerning the DLMS/COSEM specification and its use. IT has been compiled by the experts of the DLMS User Association. The answers to the questions are not intended to provide a definitive technical answer but rather to inform new users of the specification.

Feedback is welcome, in terms of comments on this document or a new questions for consideration.

Copyright: This material may be freely reproduced, except for advertising, endorsement or commercial purposes. The DLMS User Association must be acknowledged as the source.