Today's article will be about how to communicate with smart meters and other meters (gas meters, flow meters, etc.) and what ways the D2000 real-time application server offers. The blog was originally written and published in 2019 in Slovak language. Since the content is just as relevant today, we decided to translate it and publish the English version.
DLMS/COSEM standard
The DLMS (Device Language Message Specification or originally Distribution Line Message Specification) and COSEM (Companion Specification for Energy Metering) standards are developed and administered by the DLMS User Association, which brings together more than 150 manufacturers and 300 members from more than 60 countries.
These standards have also been adopted and approved as a set of international standards IEC 62056. A list of them can be found on Wikipedia (for the sake of brevity, we will not list them here).
The set of standards defines a whole set of protocols for communication with energy meters. Some (62056-21) are designed for manual data collection using a reader (HHU - handheld unit). Others define transmissions over the telephone (IEC 62056-41) and IP networks (IEC 62056-47).
The DLMS/COSEM standard organizes the measured values as well as the configuration parameters of electricity meters and other meters into an object structure. Logically related values (measured value, value timestamp, technical units, value collection parameters ...) are grouped as attributes of one object, while the list of parameters is defined by the object class.
Examples of the classes are:
Data (class_id=1): basic class with the value of the data entity accessible via the "value" attribute.
Register (class_id=3): just like Data, also, a multiplication factor is automatically applied and the technical units of the value are also given - the static attribute "scaler_unit".
Extended register (class_id=4): just like Register, also, a value timestamp is associated with the value - dynamic attribute "capture_time".
Demand register (class_id=5): Register for measuring the supply of stored energy in given periods (e.g. 1 hour or 1 day). The "last_average_value" attribute indicates the energy accumulated in the previous period, the "current_average_value" attribute indicates the energy from the current period.
Profile generic (class_id=7): a class for accessing historical values stored by meters using the "buffer" attribute.
Object addressing
Each object in DLMS/COSEM is identified by its class (16-bit class_id) and its instance_id (6-byte number), which is also called the OBIS code (Object identification system). The system for allocating and coding the individual components instance_id is specified by the IEC 62056-61 standard.
For illustration, the definition of an OBIS address according to IEC 62056-61 is as follows:
· Value group A defines the type of measured energy (energy type: 0=abstract objects, 1=electricity, 7=gas),
· Value group B defines the channel number,
· Value group C defines the measured physical quantity,
· Value group D defines the type of processing,
· Value group E defines further processing or classification according to an appropriate algorithm,
· Value group F defines the storage of processed historical data.
More on the OBIS address can be found in the IEC 62056-21: 2002 Serial protocol documentation.
The individual attributes of the objects are accessed via attribute_id (8-bit number).
This addressing method is called the Logical Name (LN) referencing by the standard.
Since the addressing of objects and their attributes in the way shown above is relatively extensive (requires 2+6+ 1 bytes), a simpler way was sought, especially suitable for less sophisticated devices. This method is called the Short Name (SN) referencing. It consists of mapping the address of an object and an attribute to a 16-bit number. At the same time, it also limits the number of objects that are addressable in the device. Each object is assigned a so-called start address (base_name). The address of a particular attribute is calculated from the start address and the attribute number as
short_name = base_name + (attribute_id - 1) * 0x08
Acquiring a list of objects
The DLMS/COSEM client can read the list of objects that are offered by the energy meter (provided that the meter implements this feature):
In SN referencing mode - using the Association SN object (class_id=12) with a fixed predefined address base_name=0xFA00.
In LN referencing mode - using the Association LN object (class_id=15) with a fixed predefined address logical_name=0.0.40.0.0.255.
In both cases, by reading attribute no. 2 (object_list) we get a list of objects - their class_id, logical_name and base_name (for SN referencing) – or the access rights to them (for LN referencing).
D2000 and DLMS/COSEM
The D2000 application server offers two different ways to obtain data from meters supporting DLMS/COSEM standards:
· communication via the KOM process
· communication via the SGCom process (Smart Grid Communicator)
Communication via the D2000 KOM
This method is suitable for applications requiring communication with few to several dozen electricity meters. It is supported by:
· text-oriented communication protocol IEC 62056-21 (a serial variant as well as a variant for working with files)
· serial communication with devices according to the DLMS/COSEM standard by binary HDLC protocol.
Both of these protocols support reading values and reading data from historical profiles. Writing is not supported (except for the time synchronization).
Communication via the SGCom process
This method is much more scalable and can handle tens to hundreds of thousands of devices. Unlike the D2000 KOM process, the configuration of electricity meters is located in a relational database and thus standard D2000 objects (line/station/measured point) are not used. This method of communication is intended for large manufacturers, or distribution companies and other entities working with a large number of energy meters.
The SGCom supports reading and writing operations, reading data from historical profiles as well as time synchronization. Access to devices via RS485 serial interface, IP network (Ethernet or GPRS) or optical interface (infrared optical head) is supported. SGCom can use both SN and LN addressing.
At the relational level, the HDLC protocol, IEC 62056-21 and also COSEM transport for IPv4 (IEC 62056-47), also referred to as DLMS/COSEM Wrapper, are supported, similarly to the D2000 KOM process.
The SGCom process supports the scheduling of periodic tasks to be performed at configuration-defined times. Whenever possible, the execution of tasks is parallelized. In addition to scheduled tasks, it is possible to enter an order to execute the task immediately:
· Reading any data from the measuring device. A typical case is the recovery of data from a time period when the measuring device was unavailable.
· Synchronization of the exact time in the measuring device
· Disconnect or connect the selected customer remotely. For example, disconnecting the defaulter until they pay the invoice for the energy supply.
In 2018, the SGCom was successfully deployed in the AMS (Advanced Metering System) project, which replaced the central system of automated metering data collection at Slovenské elektrárne (Slovak power plants). In the first half of January 2019, the AMS system was put into full operation. As part of the AMS project, the SGCom communicates with several hundred electricity billing meters.
You can read more about SGCom in the DLMS/COSEM blog in the IPESOFT D2000 environment or in the documentation.
The D2000 KOM – news in the DLMS/COSEM protocol
In January 2019, the possibilities offered by the implementation of the DLSM/COSEM protocol in the D2000 KOM process were significantly expanded. These improvements were inspired by a real need - a change in the technical conditions of the Slovak Electric Dispatching. After the change, electricity generators have to measure the supply at the threshold (i.e terminal production adjusted for their own consumption).
For this reason, we needed to communicate with modern electricity meters using the DLMS/COSEM protocol. Although this has been implemented in the D2000 KOM process since 2011, only the SN referencing addressing mode was supported. Therefore, it was necessary to support LN referencing mode and to implement time synchronization for this mode.
In the DLSM/COSEM protocol, support for reading the list of objects (browsing) was implemented in the SN referencing mode, and therefore we implemented this useful feature in the LN referencing mode as well. In addition to reading the list of objects, reading attribute values is also supported in both modes, so that the D2000 can be used as both "Object browser" and "Value browser" for DLMS/COSEM.
In addition, support for time synchronization in LN referencing mode was implemented. This is used to set the time correctly for the electricity meter (which is necessary if you need to read historical values from profiles).
Logging in to the energy meter has been extended with the possibility of entering a password (so-called Low-Level Security).
Our customers and OEM partners, therefore, have a choice of two ways of the D2000 communication with the DLMS/COSEM meters. Which one they use depends mainly on the number of meters and the properties they require. For several dozen meters, from which you only need to read data, the D2000 KOM is enough. The advantages of a dedicated SGCom can be used for a larger number of meters, wider and richer functionality, including writing values, configuring meters and possibly communication via GPRS.
In any case, the positive information is that with the help of the D2000 real-time application server, we can implement applications that work with a wide range of meters - from one to tens to hundreds of thousands of devices when scaling an application using multiple SGCom processes.
Ing. Peter Humaj, www.ipesoft.com
