The library that is used to connect to DLMS devices contains functionality to build a simulator for a device. The library offers the following core functionality.

• zero or more servers can be started on a host (different ports)

• zero or more logical devices can be registered with a server (different device id)

• zero or more annotated objects can be registered with a logical device

• these objects define available dlms classes, ObisCodes, attributeIds and methods for the device and can contain any logic

• authentication and encryption are supported

If you want to simulate a certain device you will prepare annotated classes and register instances of these with a logical device. Because you create plain Java you can make use of all functionality Java offers, for example databases. To try and make the simulation more realistic you may build in connection timeouts etc.

General Usage

For each combination of a cosem class and obiscode you create a java class that you annotate with @CosemClass(id = ..., obis = "x.x.x.x.x.255")

In these java classes you can add fields of type DataObject that you annotate with @CosemAttribute(id = ..., type = Type.x)

Also you can create getXXX and setXXX methods to intercept getting and setting data on a logical device. XXX will be the name of the corresponding field starting with a capital letter.

For example:

@CosemClass(id = 3, obis = "1.0.1.8.0.255")
public class ImportValue {

    @CosemAttribute(id = 2, type = Type.DOUBLE_LONG_UNSIGNED)
    private DataObject d1 = DataObject.newUInteger32Data(10001);

    @CosemAttribute(id = 3, type = Type.STRUCTURE)
    private DataObject d2 = DataObject.newStructureData(DataObject.newInteger8Data((byte) -2),
            DataObject.newInteger8Data((byte) 30));

    public void setD1(DataObject newData) throws IllegalAttributeAccessException {
      // ....
    }
    public DataObject getD1() throws IllegalAttributeAccessException {
      return d1;
    }
}

The value of the field will be the response to get(AttributeAddress...) that is fired from osgp CommandExecutors. NOTE that these values can also be set! For example using the ClientConsole.

You can also annotate methods with or without a DataObject return value and with or without a DataObject parameter: @CosemMethod(id = ..., consumes = Type.x)

For example:

    @CosemMethod(id = 1)
    public void hello() throws IllegalMethodAccessException {
        System.out.println("Has been called");
        return;
    }

    @CosemMethod(id = 2, consumes = Type.OCTET_STRING)
    public DataObject hello2(DataObject datO) throws IllegalMethodAccessException {
        throw new IllegalMethodAccessException(MethodResultCode.OTHER_REASON);
    }

Such a method will be called when osgp fires ClientConnection.action, the DataObject that may be returned will become available in osgp on the MethodResult object.

GXF device simulators

GXF has an implementation of DLMS device simulators that builds on the DLMS COSEM Server concepts as described in the General Usage section.

dlms-device-simulator

This project contains the code to activate a DLMS COSEM server simulating a smart meter by running the DeviceServer Spring Boot Application configure by settings defined in DlmsServerConfig.

More details about how to configure and start a simulator can be found in the readme documentation for simulators on GitHub.

The following diagrams provides some insight into the different parts that together provide access to COSEM interface object attributes and methods supported by the server.

Spring configuration classes define beans of type CosemInterfaceObject that are collected for activated Spring profiles to define the objects on the simulated device.

A COSEM interface object like octet-string deviceid1 can have a readable and writable value, that is made available outside the server and DLMS communication as well.

The role the DlmsAttributeValuesClient can play in a scenario where data is read and set from tests is described with the DLMS Attribute Values REST Resource.

DLMS Attribute Values REST Resource as used in Cucumber tests with a simulated smart meter

The Cucumber test implementation using simulated DLMS device for smart metering comprises of a number of classes spread across the following projects:

• dlms-device-simulator

• osgp-simulator-dlms-triggered

• cucumber-tests-platform-smartmetering

Dynamic values in smart meters (changed by DLMS communication or getting/setting values from test code) are implemented by using a REST resource, both from the simulated device and from the code behind Cucumber step definitions.

The following picture describes the REST resource endpoints and the way the resource is used by the different components.

DLMS/COSEM

The open smart grid platform supports DLMS/COSEM (IEC 62056]. DLMS/COSEM is a popular protocol to read smart meters. DLMS/COSEM is the de facto standard in Europe.

The open smart grid platform DLMS/COSEM implementation was initial based on SMR5 and DSMR v4. Other types of meters/profiles can be added to the platform. The open smart grid platform implementation supports HLS3/4/5.

Protocol security

• Public/private key pair(s)

• Multiple encryption levels inside protocol (DSMR requires highest encryption level)

• Full encryption of communication

Used library

The OpenMUC jDLMS library from Fraunhofer is used to implement the protocol. Please note that jDLMS is licensed under the GPLv3.

Protocol adapter configuration

DLMS protocol adapter configuration

DLMS device simulator

DLMS device simulator

Supported devices

These devices can be used in combination with the Open Smart Grid Platform.

A specific protocol adapter can be used for a specific protocol The protocol-adapter that will be used by the device, is configured in the protocol_info field of the device. The following steps are required to configure and use a specific protocol-adapter:

1. Create a protocol-adapter that listens to a specific queue

2. Add a protocol-info record that uses this queue for the requests

3. Configure the device in osgp-core, so that it will use this new protocol-info

1. osgp-protocol-adapter-dlms

Configure the name of the JMS queue on which the protocol adpater will listen for requests.

jms.dlms.requests.queue=protocol-dlms.1_0.osgp-core.1_0.cdma.requests

2. osgp-core

Protocol Info table

By using a different outgoing_requests_property_prefix value, osgp-core can use a separate JMS queue for the requests.

osgp-core.properties

The property with the prefix specified in the protocol-info table must be configured in the osgp-core.properties file The value is the name of the JMS queue. This is the same name as the name of the JMS queue specified in the osgp-protocol-adapter-dlms

jms.protocol.dlms.outgoing.cdma.requests.queue=protocol-dlms.1_0.osgp-core.1_0.cdma.requests

3. Connecting the device to the protocol-info

A device can be configured to use the specific protocol adapter, by pointing it to the new protocol_info record