CMe3100 DLMS Plugin

Product overview

Application description

The DLMS Plugin is one of the extensions (add-ons) available for the CMe3100 product. It can be ordered separately or pre-installed from the factory.

The DLMS Plugin extends the CMe3100 core services with support for DLMS over TCP/IP, providing a powerful and versatile suite of tools for Head-end System (HES) integration as well as the possibility to read and monitor any M-Bus meter using the DLMS protocol.

The Product (physical device) comprises of the management logical device (Product) and one logical device for each connected meter. The logical devices can be addressed using channel selection or logical device addressing.

The management logical device holds COSEM management objects, i.e. a list of available logical devices, clock object, channel selection etc. The meter logical devices hold COSEM objects, which represent the meter data read from the connected meters.

The meter data is automatically decoded in the Product and a meter template is used to map the M-Bus data to COSEM objects with assigned OBIS-codes. The meter template can be configured by the end user.

Meter data can be read from the Product using poll operations or data can be sent to a server using push operations (configured using the Product GUI). The push operations can be enabled to send load profiles, billing profiles, event log data and event notifications.

Standards and certification

IEC 62056 is a set of standards for Electricity metering data exchange by International Electrotechnical Commission. The IEC 62056 standards are the International Standard versions of the DLMS/COSEM specification. DLMS or Device Language Message Specification (originally Distribution Line Message Specification), is the suite of standards developed and maintained by the DLMS User Association and has been adopted by the IEC TC13 WG14 into the IEC 62056 series of standards. The DLMS User Association maintains a D Type liaison with IEC TC13 WG14 responsible for international standards for meter data exchange and establishing the IEC 62056 series. In this role, the DLMS UA provides maintenance, registration and compliance certification services for IEC 62056 DLMS/COSEM.

The Product is tested according to the specification defined in DLMS UA 1001-1 Ed. 5.0 (Yellow book) for the DLMS certification.

Installation

Uploading a new license file

The installation of the plugin is done by uploading a license file and activating the license.

  1. Log in to the web interface.

  2. Go to System > Licenses.

  3. Select Choose file in the Upload new license file section.

  4. Locate the license file you want to upload.

  5. Select Upload

    The license is now visible in the Current license(s) window.

Activating/deactivating the license

  1. Log in to the web interface.

  2. Go to Dashboard > System panel.

  3. Activate or deactivate the plugin in the Service section.

    1. To activate, toggle Enabled to the right.

    2. To deactivate, toggle Enabled to the left.

Configuration

Accessing the settings for DLMS Plugin

  • Go to the DLMS Plugin settings. The settings can be accessed in two ways:

    1. Go to Configuration > Services > DLMS.

    2. Go to Device > Licenses & Add-ons and select Elvaco-DLMS in the Add-ons list under Settings.

The default selected tab in the settings for DLMS Plugin is the Overview page which shows general information about the DLMS Plugin.

Available pages are:

  • Settings

    • General DLMS configuration for the Plugin.

  • OBIS meter mapping

    • Settings for meter mapping information from M-Bus meter data to COSEM data objects with OBIS code notation.

  • Help

    • Descriptions of the DLMS Plugin, linking to this document.

  • End-user license agreement (EULA)

Note

You need to create appropriate OBIS meter mappings for meters used in order for readout of historical data and Push Reports to work properly.

Enabling/disabling the DLMS Plugin

  1. Go to Configuration > Services > DLMS > Settings.

  2. Enable or disable the DLMS Plugin.

    1. To enable, select the checkbox for Active DLMS.

    2. To disable, clear the checkbox for Active DLMS.

  3. Select Save to store the changes.

Configuring listening TCP port number

The TCP port number is the listening port for which the Plugin will listen for incoming TCP connections. This port enables DLMS clients to access the on-board DLMS server of the Product.

The Plugin automatically restarts and starts listening on the given port once changes are saved.

  1. Go to Configuration > Services > DLMS > Settings.

  2. Enter a value in the TCP port number field.

  3. Select Save to store the changes.

Configuring value interval for profiles

The Product enables poll/push operation of three different generic profiles; Load profile 1, Load profile 2, and Billing profile.

All three profiles can be configured individually to allow maximum flexibility regarding what value interval that is of interest.

  1. Go to Configuration > Services > DLMS > Settings.

  2. Select a value for each profile. Available values are:

    • All values

    • 5 minutes

    • 10 minutes

    • 15 minutes

    • 20 minutes

    • 30 minutes

    • 1 hour

    • 12 hours

    • 1 day

    • 1 month

    Note

    The value interval needs to be an even multiple of the meter readout schedule (Meters > Readout schedule). For example, setting the meter readout schedule to 15 minutes and selecting 1 hour for load profile 1 will return every 4th value read from the meters.

    Selecting All values will result in using the same value interval as configured for the meter readout schedule.

  3. Select Save to store the changes.

Configuring security policy

The Product supports security suite 0 with none, low level or high level security.

  1. Go to Configuration > Services > DLMS > Settings.

  2. Select a value for Security policy.

  3. Select Save to store the changes.

The security policy can also be changed using the DLMS protocol.

For security purposes the security policy can only be increased using the DLMS protocol. This means that if the security policy should be decreased, it must be done through using the GUI or any other configuration API for the Product.

OBIS meter mapping

The OBIS meter mapping page is used to configure the mapping information needed to translate M-Bus meter values to readable COSEM objects.

The mapping table allows a M-Bus meter to be accessed using DLMS through mapping one or more M-Bus meter value fields to corresponding OBIS codes (and COSEM objects). Meter mappings can be created for a particular meter type, manufacturer and version or made generic for any meter of a specific type such as water, electricity etc.

Note

You need to create appropriate OBIS meter mappings for meters used in order for readout of historical data and Push Reports to work properly.

Recommended approach to meter mapping

Always strive for a common global mapping file that works for all meters in the system. This can be accomplished through for example:

  • A generic mapping file for all meter of a particular type (water/heat/…) and, if needed, mapping several different M-Bus keys to the same OBIS code. The latter will bridge differences in how the M-Bus keys are used in different meters.

  • M-Bus keys doesn’t have to be present for all meters that are matched by the meter mapping file. This gives the possibility to use the same mapping file even if some meters don’t support some of the M-Bus keys specified in the meter mapping file.

Active meter mappings

The Active meter mappings section shows the current active meter mappings and for which meters they will be applied depending on if they match the meter type, manufacturer and version (based on M-Bus header information read from the meter). These fields can also be set to “all” if the meter mapping should be applied regardless of for example manufacturer or version.

The OBIS Codes column shows the number of mapped M-Bus value fields to COSEM register objects. If there is no mapping for a specific M-Bus value, the DLMS Plugin will exclude that value in all poll/push operations and it will not be accessible.

Adding a new or updated meter mapping file

The new or updated meter mapping file will be available under Active meter mapping section.

  1. Go to Configuration > Services > DLMS > OBIS meter mapping.

  2. Select Choose file in the Choose file to import section.

  3. Locate the file you want to import.

  4. Select Add.

Deleting a meter mapping file

  1. Go to Configuration > Services > DLMS > OBIS meter mapping.

  2. Select the trash can icon in the Option column of the Active meter mapping section.

Meter types in use

This section shows available/installed meters in the product. By clicking the download icon, a template file is downloaded which serves as a good starting point for creating the OBIS meter mapping file. It contains all M-Bus fields available from the particular meter in the correct template format, ready to use as a meter mapping file.

Note

The CMe3100 must have done at least one readout from the meter before the template file is downloaded, otherwise the M-Bus value information will be empty.

Creating or modifying a meter mapping file

  1. Go to Configuration > Services > DLMS > OBIS meter mapping.

  2. Download template file.

    1. To create a new meter mapping file, download it in Meter types in use section.

    2. To modify an existing meter mapping file, download it in Active meter mappings section.

  3. Update the contents of the file by connecting OBIS codes with corresponding M-Bus keys (VIF/DIF combinations). All OBIS codes must be configured for each entry in the mapping, in order for the value to be available over DLMS.

    Tip

    The mapping files are in JSON format and can be edited in a text editor, preferably one that has support for highlighting JSON.

The mapping can be made for a specific meter or made generic by setting manufacturer to “all” and/or version to 0. It is also possible to map several M-Bus keys, even from meters with different versions or manufacturers, to the same OBIS code. This allows you to create mapping files that handles for example meters which has differences between versions and/or manufacturers.

When using a generic mapping file it is also possible to combine it with other meter mapping files for specific manufacturers and/or a specific versions if they need to be handled in a different way. This is accomplished by the way the mapping files are applied, they use a predefined matching order as shown in the following list. The first file that matches the criteria will be used. A meter mapping file which has manufacturer and/or version set to a specific value will be used instead of a generic mapping file if the manufacturer and/or version is matching for a particular meter.

  1. Matching type, manufacturer, and version.

  2. Matching type, manufacturer, and generic version.

  3. Matching type, generic manufacturer, and generic version.

Meter mapping file example

Meter mapping file example

The previous example file matches all water meters and doesn’t care about manufacturer or version. The translation entry will map both m-bus values with internal keys: "mbus.dib.volume.0.0.0.0.unmodifiedvalue" and "mbus.dib.0c13.unmodifiedvalue" to the same OBIS object: 8.0.1.0.0.255. If a new meter is added with a different DIF/VIF combination for the same value it could simply be supported by adding that new DIF/VIF to the list of “mbusKeys”.

Simplified mapping

Simplified mapping allows all data to be queried over DLMS without mapping meter specific M-Bus keys (VIF/DIF combinations) to OBIS code.

There are two different ways to use simplified mapping:

  1. Retrieving raw M-bus data.

  2. Retrieving decoded M-bus data.

Raw M-bus data and decoded M-bus data can be retrieved over DLMS, by using the corresponding keys in the following table. This is useful when using meters from multiple manufacturers.

Table 122. Simplified M-bus keys

M-bus key

Suggested OBIS code

COSEM type

Description

mbus.frame.raw

0.0.1.1.128.255

Data / octet-string

Raw M-bus data

mbus.telegram.decoded.value

0.0.1.2.128.255

Data / visible-string

Decoded M-bus data

mbus.telegram.decoded.header

0.0.1.3.128.255

Data / visible-string

Headers for decoded M-bus data


Retrieving raw M-bus data
  • Map an OBIS code to the “mbus.frame.raw” key.

    The M-bus data will be provided in the same way as if it was retrieved directly from the meter.

Tip

This is useful when the HES system handles decryption and decoding.

Mapping sample

The following is a sample of how to map an OBIS code for getting raw M-bus data:

...

{

"includeInPush": "ALL",

"mbusTelegram": 0,

"mbusKeys": ["mbus.frame.raw"],

"dlmsObisCode": "0.0.1.1.128.255",

"dlmsScaler": 0,

"dlmsUnit": 0,

"dlmsClass": "data",

"dlmsDataType": 9,

"dlmsDefaultValue": null,

"mbusUnit": null,

"mbusDescriptionLong": null,

"mbusTariff": null,

"mbusStorageNumber": 0,

"mbusSubUnit": null,

"mbusFunction": null

}

...

Retrieving decoded data
  1. Map an OBIS code to “mbus.telegram.decoded.value” for M-bus values.

  2. Map an OBIS code to “mbus.telegram.decoded.header” for header information.

Note

Always read both header and value information, as headers can change over time for a specific meter, for example as a result of a configuration change to the meter.

Example header

#serial-number;device-identification;created;value-data-count;manufacturer;version;device-type;access-number;status;signature;dif=0c,vif=78,description=fabrication-no,kind=inst-value,tariff=0,subunit=0,storagenumber=0;dif=07,vif=7a,description=address,kind=inst-value,tariff=0,subunit=0,storagenumber=0;dif=0c,vif=13,unit=m3,description=volume,kind=inst-value,tariff=0,subunit=0,storagenumber=0;dif=8c10,vif=13,unit=m3,description=volume,kind=inst-value,tariff=1,subunit=0,storagenumber=0;dif=0b,vif=3b,unit=m3/h,description=volume-flow,kind=inst-value,tariff=0,subunit=0,storagenumber=0;dif=02,vif=5a,unit=°C,description=flow-temp,kind=inst-value,tariff=0,subunit=0,storagenumber=0;dif=02,vif=fd70,description=datetime-of-battery-change,kind=inst-value,tariff=0,subunit=0,storagenumber=0;dif=0b,vif=26,unit=hour(s),description=op-time,kind=inst-value,tariff=0,subunit=0,storagenumber=0;dif=0a,vif=a618,unit=hour(s),description=op-time data-error,kind=inst-value,tariff=0,subunit=0,storagenumber=0;dif=04,vif=6d,description=datetime,kind=inst-value,tariff=0,subunit=0,storagenumber=1

Example values

0016000000;-2147483648;2000-01-01 01:00:00;00;HYD;37;water;10;0;0;47559461;47559461;85,946;0,000;0,000;27,300;14399;22525;167;2016-01-06 16:50:00

Mapping sample

The following is a sample of how to map OBIS codes for getting decoded M-bus data:

...

{

"includeInPush": "ALL",

"mbusTelegram": 0,

"mbusKeys": ["mbus.telegram.decoded.value"],

"dlmsObisCode": "0.0.1.2.128.255",

"dlmsScaler": 0,

"dlmsUnit": 0,

"dlmsClass": "data",

"dlmsDataType": 10,

"dlmsDefaultValue": null,

"mbusUnit": null,

"mbusDescriptionLong": null,

"mbusTariff": null,

"mbusStorageNumber": 0,

"mbusSubUnit": null,

"mbusFunction": null

},{

"includeInPush": "ALL",

"mbusTelegram": 0,

"mbusKeys": ["mbus.telegram.decoded.header"],

"dlmsObisCode": "0.0.1.3.128.255",

"dlmsScaler": 0,

"dlmsUnit": 0,

"dlmsClass": "data",

"dlmsDataType": 10,

"dlmsDefaultValue": null,

"mbusUnit": null,

"mbusDescriptionLong": null,

"mbusTariff": null,

"mbusStorageNumber": 0,

"mbusSubUnit": null,

"mbusFunction": null

},

...

Excluding OBIS codes from push reports

Note

By default, all OBIS codes included in a mapping file will be included in all push reports for matching meters.

  • Remove a specific OBIS code by one of the following ways:

    • Remove it from the mapping file, thus making it unavailable over DLMS.

    • Set the property “includeInPush” to “NONE”.

Meter mapping file properties

Table 123. Top-level properties

Property name

Type

Description

type

String

The type of meter that this translation applies to.

manufacturer

String

A three letter manufacturer code for which meter manufacturers this mapping applies to.

Use all to match all manufacturers.

version

Integer

Numeric value for which meter version this mapping applies to.

Use 0 to match all versions.

entries

JSON array

Translation entries defining the mapping between one or more M-Bus keys to a DLMS OBIS code.


Table 124. Sub-properties for property entries (list of translation entries)

Property name

Type

Description

dlmsClass

String

COSEM type [clock, register, data, profile_generic]

dlmsDataType

Integer

DLMS type

dlmsDefaultValue

String

Default value used if a value is missing for the key.

For no value use null

dlmsScaler

Integer

Numeric value used to scale the meters value. The value may be negative. This is the exponent (to the base of 10) of the multiplication factor.

dlmsUnit

Integer

Measure unit

mbusDescriptionLong

String

Not used.

mbusFunction

String

Not used.

includeInPush

String

Include this obis code in push reports, default is ALL [NONE, ALL]


Configuration of push reports

DLMS Plugin Push Report support enables the CMe3100 to send DLMS Push Report to a HES with:

  • Load profile data

  • Billing profile data

  • Standard event log (gateway and meters)

  • Fraud detection log data (gateway and meters)

  • Push notification – Notify a DLMS client when the meter list has changed

Up to five different reports can be scheduled to run simultaneously. Each report has individual settings with regards to type of report (load profile, billing profile, event log etc.), schedule, server address and fallback server address.

The push report configuration page is accessed in Configuration > Push Reports.

Enabling/disabling push notifications

  1. Go to Configuration > Push Reports > DLMS settings.

  2. Enable or disable the push notifications.

    1. To enable, select the checkbox for Push notification when meter list changed.

      When enabled, the product will send an event to the default DLMS server when a meter is added, updated or removed.

    2. To disable, clear the checkbox for Push notification when meter list changed.

Configuring default DLMS server settings

  1. Go to Configuration > Push Reports > DLMS settings.

  2. Enter the default server address (IP or hostname) in the Default address field.

  3. Enter the TCP port to be used when sending push reports in the Port field.

  4. To use a fallback if a push report fails when trying to connect to the default server, enter a Backup address and Port below the default address and port.

  5. Select or clear the checkbox for Encrypt communication to enable or disable.

Configuring individual push reports

  1. Go to Configuration > Push Reports and select the report in the list you want to configure.

  2. Select DLMS in the Report type dropdown menu.

  3. Select a profile in Report template dropdown menu.

    1. To configure push report of load profile/billing profile, select 9010 (Load profile1), 9011 (Load profile 2) or 9012 (Billing profile).

    2. To configure push report of standard event log, select 9001 (Standard event log).

    3. To configure push report for fraud detection log, select 9002 (Fraud detection log).

    Each report will push all events for both the gateway and the meters.

  4. Select a schedule for the report in the Report schedule dropdown menu.

    Note

    The report schedule should be a multiple of the meter readout schedule. The report is sent as soon as the last meter readout cycle has completed. For example, setting the meter readout schedule to 15 minutes and selecting 1 hour for load profile 1, a report will be sent as soon as every 4th readout cycle completes.

    Note

    The Read out schedule meters is read-only, and shows the current read out schedule for meters connected to the product.

  5. Select the values to include in the report based on how long ago they were stored compared to when the report is sent in the Report content section. Use "Auto” to include all values not sent since last report was sent.

    Note

    The Value interval is defined by the load profile/billing profile setting.

  6. Select the checkbox for Send report to default DLMS server to use the default server settings for DLMS servers that receive the push report.

  7. If the default server settings should not be used, clear the checkbox for Send report to default DLMS server and enter the desired DLMS server in Default address and Port.

  8. Enter Backup address and Port to use a fallback server if the report fails when sending report to the default address.

  9. To trigger a test report, select Save and Send test report.

DLMS implementation and integration

HES operations

This is an overview of what's possible to do with the Product from a HES via DLMS.

  • Polling operations using TCP/IP and xDLMS Services

    • Detection of logical devices using SAP Assignment

    • Detection of COSEM objects using association LN (Long Names)

    • Read load and billing profiles of connected M-Bus meters

    • Read event logs

    • Configure security for none, low level security and high level security mode 5 (GMAC)

    • Logical device addressing or channel selection

  • Push operations using TCP/IP using Push Notification Services

    • Up to 5 different push setups with:

      • Individually configurable schedules

      • Automatic retries and resending of unsent report data (e.g. due to network connectivity problems)

      • Jittered timestamp for transmission (load balancing receiving servers)

      • Fall-back server address

    • Push of load and billing profile

    • Push of event logs (standard events and fraud detection)

    • Push event “On Installation” – notification when meter list changed

Session establishment between HES and the Gateway using poll operations

The HES connects to the Gateway using TCP/IP. The HES associates with the Gateway on the DLMS/COSEM application layer using the following security features:

  • Security suite 0

  • Authentication: None, Low Level Security or High Level Security mode 5 (see DLMS UA 1000-2 Ed. 8.0 (Green book), 9.2.74)

  • Security policy: “None” or “Authenticated and encrypted” (see DLMS UA 1000-2 Ed. 8.0 (Green book), 9.2.7.2.3)

  • Server System title according to IDIS (see IDIS Package 2 IP profile Ed 2.0, 6.1.1)

  • Client SAP: 1 (management client) or 16 (public client)

  • Server SAP: 1 (management logical device), 16..n (meter logical device)

Server system title according to IDIS

The system title is 8 bytes long and is coded according to IDIS (see IDIS Package 2 IP profile Ed 2.0, 6.1.1):

Table 125. 

Byte 1

Byte 2

Byte 3

Byte 4

Byte 5

Byte 6

Byte 7

Byte 8

MC

MC

MC

T1b

T2b, SNb

SNb

SNb

SNb


MC: Manufacturer Code according to FLAG Association as ASCII characters

T1b: IDIS Meter Device Type (Always set to 0)

T2b : IDIS Meter Function Type (Always set to 0)

SNb:Manufacturer specific serial number (28 bits, low nibble of byte 5 and byte 6..byte 8). Taken from the gateway serial number and represented as a binary 28 bit integer with MSByte order, right justified to byte 8.

The system title is built up from the logical device name of management logical device name.

Example

Management logical device name (gateway logical device name):

ASCII characters: ELV000016000000

String hex representation: 0x454C56303030303136303030303030

System title:

Byte array hex representation: 0x454C560000F42400

Security authentication mechanisms

There are three different authentication mechanisms in DLMS; No security authentication, Low Level Security (LLS) authentication, and High Level Security (HLS) authentication.

The authentication level is specified by the DLMS client when connecting to the Product.

No security (lowest level security) authentication

The purpose of No security (lowest level security) authentication is to allow the client to retrieve some basic information from the server. Typically, this is topology information including the name and the association view of the device.

This security mechanism is accepted only for the public client (id 16).

Low Level Security (LLS) authentication

When using LLS authentication the server requires that the client authenticates itself by supplying a password that is known by the server.

The password is by default set to 12345678. If this key is used for authentication, it's highly recommended to change the key after installing the DLMS plugin. The password can be changed in the Security section in Configuration > Services > DLMS > Settings or by the HES.

High Level Security (HLS) authentication

When running HLS authentication, both the client and the server have to successfully authenticate themselves to establish a connection (in DLMS known as Application Association or AA). It is a four-pass process and there are several HLS authentication mechanisms available, e.g. GMAC. HLS requires a block cypher key to encrypt and decrypt messages sent between client and server.

For additional security an authentication key denoted AK is also specified. DLMS/COSEM supports something called key exchange which is a process of securely change encryption keys. When doing such an exchange the Key Encrypting Key (KEK) is used to wrap the keys before sending them. KEK is also known as the DLMS Master Key.

See Table 126, “Encryption keys description” for more information about the keys and their usage.

Table 126. Encryption keys description

Key

Description

Master Key / Key Encryption Key (KEK)

A key encrypting key (KEK) is used to encrypt/decrypt other symmetric keys. In DLMS/COSEM this is the master key. KEK is used by DLMS client and server when exchanging keys.

The key must be at least 16 characters long.

Authentication key

In DLMS, for additional security, an authentication key denoted AK is also specified. When present, it shall be part of the Additional Authenticated Data, AAD.

The key must be at least 16 characters long.

Block cipher key

The block cipher key, also known as Encryption Key (EK), is used in the AES-GCM algorithm.

The key must be at least 16 characters long.


All keys will be automatically generated the first time the DLMS plugin starts and can be updated in two ways:

  • Via the Security section in Configuration > Services > DLMS > Settings.

  • By the HES.

Addressing of logical devices

The logical devices can be addressed using the logical device address or a manufacturer implemented channel selection mechanism. The channel and the logical device address are mapped one to one (same numeric value).

The manufacturer specific channel selection mechanism is implemented to reduce the handshaking overhead and enables the HES to access all logical devices in one single association.

Logical device addressing

The management logical device can be addressed using logical device address 1. Connected M-Bus meters (meter logical devices) are addressed using logical device address 16..n.

A gateway with a single M-Bus meter connected will consequently have two accessible logical devices; the management logical device at address 1 and the meter logical device at address 16. If more meters are connected, the next free logical device address will be used, i.e. 17.

Logical device addressing can only be performed during session establishment.

Channel selection

Channel selection is available after successful association with any of the logical devices.

Channel selection can be used to address and access the different logical devices in the physical device (gateway). The manufacturer specific OBIS code 0.128.1.0.0.255 has been assigned for this purpose. The COSEM object is of interface class Data (1). The object holds a single LongUnsigned integer, which is readable and writable on all logical devices.

The default channel selected after a successful association is the same as the logical device address.

The HES sets the value of this object using xDLMS SET Service. Following APDU (XML formatted for readability) shows theformat of such request selecting the management logical device:

<SetRequest>
  <SetRequestNormal>
    <InvokeIdAndPriority Value="C1" />
    <AttributeDescriptor>
      <ClassId Value="0001" />
      <InstanceId Value="0080010000FF" />
      <AttributeId Value="02" />
    </AttributeDescriptor>
    <Value>
      <Long-Unsigned Value="01" />
    </Value>
  </SetRequestNormal>
</SetRequest>

Querying data from the gateway using poll operation

After successful association, the logical device to address can be changed using channel selection. The gateway will stay on the current selected logical device until disconnect or a new channel selection is made during the same session.

Depending on selected logical device and the client id, different COSEM objects are available.

Management logical device COSEM objects

Following COSEM objects are available in the management logical device:

Table 127. Management logical device COSEM Objects

Description

OBIS Code

Interface Class

Access


A

B

C

D

E

F

Public client (16)

Management client (1)

SAP Assignment

0

0

41

0

0

255

SAP Assignment (17)

R

R

Association LN

0

0

40

0

0

255

Association LN (15)

R

RW

Clock

0

0

1

0

0

255

Clock (8)

R

RW

Logical Device Name

0

0

42

0

0

255

Data (1)

R

R

Receive Frame Counter

0

0

43

1

0

255

Data (1)

R

R

Channel Selection

0

128

1

0

0

255

Data (1)

None

RW

Meter List

1

128

0

0

0

255

Data (1)

None

R

Gateway System Title

0

0

96

1

0

255

Data (1)

None

R

Gateway Firmware Version

1

0

0

2

0

255

Data (1)

None

R

Gateway Firmware Signature

1

1

0

2

8

255

Data (1)

None

R

Gateway IP Address

0

0

96

128

0

255

Data (1)

None

R

Standard Event Log - Event Id

0

0

96

11

0

255

Data (1)

None

R

Standard Event Log - Event Message

0

128

96

11

0

255

Data (1)

None

R

Fraud Event Log - Event Id

0

0

96

11

1

255

Data (1)

None

R

Fraud Event Log - Event Message

0

128

96

11

1

255

Data (1)

None

R

Specific Test Object

0

0

96

1

4

255

Data (1)

None

RW

Standard Event Log

0

0

99

98

0

255

Profile Generic (7)

None

R

Fraud Event Log

0

0

99

98

1

255

Profile Generic (7)

None

R

Push Setup Gateway Standard Event Log

0

4

25

9

0

255

Push Setup (40)

None

R

Push Setup Gateway Fraud Event Log

0

8

25

9

0

255

Push Setup (40)

None

R

Push Setup On Install

0

7

25

9

0

255

Push Setup (40)

None

R

Security Setup

0

0

43

0

0

255

Security Setup (64)

None

RW

SAP Assignment

SAP Assignment object can be read from the gateway to identify available logical devices.

Association LN

This object holds the list of available COSEM objects on current selected logical device.

This object can also be used by the HES to set the LLS authentication password.

Clock

The clock object enables read/write of the internal gateway real time clock.

Logical Device Name

Data type: octet-string

This object holds the logical device name of the gateway, 13 characters octet string. The format of the logical device name is according to the following pattern:

ELV <serial number> Example: ELV0016000001

Receive Frame Counter

Data type: double-long-unsigned

This object holds the current value of the frame counter (invocation counter) needed for encrypted communication.

The gateway will drop any message carrying a frame counter with the value less than the gateway current value.

Channel Selection

Data type: long-unsigned

This object enables switching between all logical devices during a single association.

Meter list

The meter list contains a list of meters, representing the meter logical device name and the corresponding channel, which can be used for channel selection.

The APDU (XML formatted for readability) of the meter list should have the following format:

<structure>
  <octet-string>COSEM logical device name of the gateway</octet-string>
  <array>
    <structure>
      <octet-string>COSEM logical device name of meter 1</octet-string>
      <long-unsigned>Channel of meter 1</long-unsigned>
    </structure>
    <structure>
     ...
    </structure>
    <structure>
      <octet-string>COSEM logical device name of meter n</octet-string>
      <long-unsigned>Channel of meter n</long-unsigned>
    </structure>
  </array>
</structure>
Gateway System Title

Data type: octet-string

This object holds the system title of the gateway.

Gateway Firmware Version

Data type: octet-string

This object holds the gateway firmware version information.

Gateway Firmware Signature

Data type: octet-string

This object holds the gateway firmware signature information.

Gateway IP Address

Data type: double-long-unsigned

This object holds the gateway IPv4 address numeric representation.

For example, the address 192.168.1.2 is represented as 0xC0A80102, decimal value 3232235778.

Standard Event Log – Event Id

Data type: long-unsigned

This object holds the event id of the last event logged to Standard Event Log.

Standard Event Log – Event Message

Data type: visible-string

This object holds the event description of the last event logged to Standard Event Log.

Fraud Event Log – Event Id

Data type: long-unsigned

This object holds the event id of the last event logged to Fraud Event Log.

Fraud Event Log – Event Message

Data type: visible-string

This object holds the event description of the last event logged to Fraud Event Log.

Specific Test Object

Data type: octet-string

This object is used for testing and it should be ignored. It doesn’t hold any information.

Standard event log and fraud detection log

The standard event log is a table of log items of type Profile Generic with gateway related log items. The data which can be read from the log is date/time of event and event code.

Attributes:

  1. Logical name

  2. Buffer (actual data)

    Selector 0 (all data) and selector 1(from-to) implemented

  3. Capture objects (list of OBIS codes)

  4. N/A

  5. N/A

  6. N/A

  7. Entries in use in the database

  8. Entries in use in the database

COSEM objects/OBIS codes:

Date/Time: 0.0.1.0.0.255

Event object: 0.0.96.11.0.255 (Standard), 0.0.96.11.1.255 (Fraud)

Event message: 0.128.96.11.0.255 (Standard), 0.128.96.11.1.255 (Fraud)

Limitations:

Maximum of 1000 rows can be read in one request.

See CMe3100 Log Events for available log items.

Push Setup Gateway Standard Event Log

The push setup object holds the information about the objects to be included in the Standard Event Log Push report.

Push Setup Gateway Fraud Event Log

The push setup object holds the information about the objects to be included in the Fraud Event Log Push report.

Push Setup On Installation

The push setup object holds the information about the objects to be included in the On Installation Event Push report.

Security setup

The security setup object enables read/write of keys and policy used in security suite 0.

For the key exchange, the HES calls methods of the security setup (version 0), OBIS code 0.0.43.0.0.255. The only keys that are to be exchanged are those of the gateway. There are no separate keys for the meters. The key exchange is to be executed as specified by DLMS UA 1000-2 Ed. 8.0 (Green book), sectiob 9.2.5.4 and IDIS Package 2 IP profile Ed 2.0, section 9.4.6.1.

When writing to the security setup object, the new security configuration will NOT be used until a disconnect and a new connection is made.

Meter logical device COSEM objects

Following COSEM objects are available in each meter logical device:

Table 128. Meter logical device COSEM objects

Description

OBIS Code

Interface Class

Access


A

B

C

D

E

F

Public client (16)

Management client (1)

SAP Assignment

0

0

41

0

0

255

SAP Assignment (17)

R

R

Association LN

0

0

40

0

0

255

Association LN (15)

R

RW

Clock

0

0

1

0

0

255

Clock (8)

R

RW

Logical Device Name

0

0

42

0

0

255

Data (1)

R

R

Receive Frame Counter

0

0

43

1

0

255

Data (1)

R

R

Channel Selection

0

128

1

0

0

255

Data (1)

None

RW

Gateway Logical Device Name

1

128

2

0

0

255

Data (1)

None

R

Meter Firmware Version

1

0

0

2

8

255

Data (1)

None

R

Meter Manufacturer Id

0

0

96

128

1

255

Data (1)

None

R

Meter Device Type

0

0

96

128

2

255

Data (1)

None

R

Standard Event Log - Event Id

0

0

96

11

2

255

Data (1)

None

R

Standard Event Log - Event Message

0

128

96

11

2

255

Data (1)

None

R

Fraud Event Log - Event Id

0

0

96

11

3

255

Data (1)

None

R

Fraud Event Log - Event Message

0

128

96

11

3

255

Data (1)

None

R

Specific Test Object

0

0

96

1

4

255

Data (1)

None

RW

Load Profile 1

8

0

99

1

0

255

Profile Generic (7)

None

R

Load Profile 2

8

0

99

2

0

255

Profile Generic (7)

None

R

Billing Data

8

0

98

1

0

255

Profile Generic (7)

None

R

Standard Event Log

8

0

99

98

2

255

Profile Generic (7)

None

R

Fraud Event Log

8

0

99

98

3

255

Profile Generic (7)

None

R

Push Setup Meter Load Profile 1

0

1

25

9

0

255

Push Setup (40)

None

R

Push Setup Meter Load Profile 2

0

2

25

9

0

255

Push Setup (40)

None

R

Push Setup Meter Billing Data

0

3

25

9

0

255

Push Setup (40)

None

R

Push Setup Meter Standard Event Log

0

4

25

9

0

255

Push Setup (40)

None

R

Push Setup Meter Fraud Event Log

0

8

25

9

0

255

Push Setup (40)

None

R

Security Setup

0

0

43

0

0

255

Security Setup (64)

None

R

M-Bus registers dynamically created from available data in the M-Bus meter representing the meter logical device X=According to OBIS meter mapping

X

X

X

X

X

X

Register (3)

None

R

M-Bus data dynamically created from available data in the M-Bus meter representing the meter logical device X=According to OBIS meter mapping

X

X

X

X

X

X

Data (1)

None

R

SAP Assignment

SAP Assignment object can be read from the gateway to identify available logical devices.

Association LN

This object holds the list of available COSEM objects on current selected logical device.

The COSEM objects for a specific meter logical device is a reflection of the available data registers read from an M-Bus meter which has valid mapping information in the OBIS meter mapping and the static objects according to previous table.

Clock

The clock object enables read/write of the internal gateway real time clock.

Logical Device Name

Data type: octet-string

This object holds the logical device name of the meter, 13 characters octet string. The format of the logical device name is according to the following pattern:

<man><type><version><serial number> Example: ELV010112345678

Where

<man> = Three capital letter manufacturer number according to Flag Association representing the meter manufacturer.

<type> = Two digit ASCII hex (one byte) type/medium of meter according to IDIS Package 2 IP profile Ed 2.0, section 5.8 representing the meter medium.

<version> = Two digits ASCII hex (one byte) version of the meter.

Receive Frame Counter

Data type: double-long-unsigned

This object holds the current value of the frame counter (invocation counter) needed for encrypted communication.

The gateway will drop any message carrying a frame counter with the value less than the gateway current value.

Channel Selection

Data type: long-unsigned

This object enables switching between all logical devices during a single association.

Gateway Logical device name

This object is a mirror of the logical device name of the gateway and is accessible on all meter logical devices in the gateway. This enables read of the gateway logical device name when associating/addressing a meter logical device.

Meter Firmware Version

Data type: octet-string

This object holds the meter firmware version information.

Meter Manufacturer Id

Data type: octet-string

This object holds the meter manufacturer id information.

Meter Device Type

Data type: integer

This object holds the meter MBus device type information.

Standard Event Log – Event Id

Data type: long-unsigned

This object holds the event id of the last event logged to Standard Event Log.

Standard Event Log – Event Message

Data type: visible-string

This object holds the event description of the last event logged to Standard Event Log.

Fraud Event Log – Event Id

Data type: long-unsigned

This object holds the event id of the last event logged to Fraud Event Log.

Fraud Event Log – Event Message

Data type: visible-string

This object holds the event description of the last event logged to Fraud Event Log.

Specific Test Object

Data type: octet-string

This object is used for testing and it should be ignored. It doesn’t hold any information.

Billing profile and Load profile 1 & 2

The billing profile is a table with all registers read from the M-Bus meter which contains valid mapping in the OBIS meter mapping.

Attributes:

  1. Logical name

  2. Buffer (actual data)

    Selector 0 (all data) and selector 1(from-to) implemented

  3. Capture objects (list of OBIS codes)

  4. N/A

  5. N/A

  6. N/A

  7. Entries in use in the database

  8. Entries in use in the database

COSEM objects/OBIS codes:

Date/Time: 0.0.1.0.0.255

M-Bus registers: Depends on the OBIS meter mapping file.

Limitations:

Maximum of 1000 rows can be read in one request.

Standard event log and fraud detection log

The standard event log is a table of log items of type Profile Generic with meter related log items. The data which can be read from the log is date/time of event and event code. The event code is the status byte read from the M-Bus meter + base value (4000). This gives the possibility to get the actual M-Bus status code readable from the event code value (4000..4255). Log items will only be created in the log if the M-Bus status byte changes between readout.

The fraud detection log contains a table of log items of type Profile Generic with meter related log items. The data which can be read from the log is date/time of event and event code.

Currently there are no fraud detection log items in the meter fraud detection log, i.e. reading the log will return zero (0) rows.

Attributes:

  1. Logical name

  2. Buffer (actual data)

    Selector 0 (all data) and selector 1(from-to) implemented

  3. Capture objects (list of OBIS codes)

  4. N/A

  5. N/A

  6. N/A

  7. Entries in use in the database

  8. Entries in use in the database

COSEM objects/OBIS codes:

Date/Time: 0.0.1.0.0.255

Event object: 0.0.96.11.0.255 (Standard), 0.0.96.11.1.255 (Fraud)

Event message: 0.128.96.11.0.255 (Standard), 0.128.96.11.1.255 (Fraud)

Limitations:

Maximum of 1000 rows can be read in one request.

See CMe3100 Log Events for available log items.

Push Setup Meter Load Profile 1

The push setup object holds the information about the objects to be included in the Load Profile 1 Push report.

Push Setup Meter Load Profile 2

The push setup object holds the information about the objects to be included in the Load Profile 2 Push report

Push Setup Meter Billing Data

The push setup object holds the information about the objects to be included in the Billing Data Push report.

Push Setup Gateway Standard Event Log

The push setup object holds the information about the objects to be included in the Standard Event Log Push report.

Push Setup Gateway Fraud Event Log

The push setup object holds the information about the objects to be included in the Fraud Event Log Push report.

Security setup

The security setup object enables reading of the security parameters.

The keys and policy can be changed only in the gateway instance of the security setup object.

M-Bus data and registers

Available M-Bus registers are mapped into COSEM objects according to the OBIS meter mapping.

All M-Bus registers are of type interface class Register and contains the attributes value, unit and scaler. The translation from M-Bus register data to COSEM object tries to keep the original data type as far as possible, which means that integers are treated as integers, floats as floats etc.

In order to minimize the load on the meters the DLMS plugin has a caching mechanism for M-Bus registers.

When reading M-Bus registers the DLMS plugin will first look in the cache for the value. If it exists, and the timestamp of the value is less than 60 seconds old, the value is returned to the caller.

If the value is older or does not exist in the cache, a readout from the meter is done. This operation will interrupt any readout cycles in case they are running.

If the readout is successful, the value is written to cache and returned to the caller. In the case of a failing meter readout, the plugin will return the last known value, if it exists in the cache, otherwise a DLMS error message is generated.

Reading a COSEM object (included in a meter template), which contains no valid data, will return the default error value defined in the meter template.

Push notifications

The gateway supports to push data periodically or push data on events.

Push notifications are sent using Data-Notification-Service.

Periodical push data

Push profiles

Profiles are pushed according to configured schedule via the Data-Notification-Service for all connected meters. A push contains data from one meter. It may contain data from multiple profiles. The payload of the Data Notification APDU has the following structure:

<octet-string>COSEM logical device name of the gateway</octet-string>
<octet-string>COSEM logical device name of the meter</octet-string>
<octet-string>COSEM logical name of the push setup object</octet-string>
<octet-string>COSEM logical name of profile</octet-string>
<array>
    <structure>capture object 1</structure>
    ...
    <structure>capture object m</structure>
</array>
<array>
    <structure>profile buffer entry 1</structure>
    ...
    <structure>profile buffer entry n</structure>
</array>
<array>
    <structure>unit and scaler for register 1 stored in profile</structure>
    ...
    <structure>unit and scaler for register m stored in profile</structure>
</array>

Each capture object must contain the following elements:

<long-unsigned>interface class ID</long-unsigned>
<octet-string>COSEM logical name</octet-string>
<integer>attribute index</integer>
<long-unsigned>data index</long-unsigned>

See DLMS UA 1000-1 Ed. 12.0 (Blue book), section 4.3.6

Each profile buffer entry must contain the following elements:

<octet-string>timestamp</octet-string>
<some datatype>value</some data type>
<some datatype>value</some data type>
<some datatype>value</some data type>
...

See DLMS UA 1000-1 Ed. 12.0 (Blue book), section 4.3.6

Each unit and scaler object contains the following elements:

<integer>scaler</integer>
<enum>unit</enum>

See DLMS UA 1000-1 Ed. 12.0 (Blue book), section 4.3.2

Push event logs

Event logs (gateway and meters) are pushed according to configured schedule via the Data-Notification Service.

A push contains data from a single logical device (gateway or meter). It may contain data from multiple event logs. Standard event log is available for both meter logical device and gateway logical device. The fraud detection log is only available for gateway logical device as the actual meaning of the meter event (which may be manufacturer specific) is not decoded by the gateway. Hence all meter events are placed in the “Meter status” event section available through the standard event log.

See CMe3100 Event logs for available log items. The standard event log contains all events but those in the “Security” event section. The fraud detection log only contains events from the “Security” event section.

The payload of the Data Notification APDU has the following structure for Gateway logical device (management device):

<octet-string>COSEM logical device name of the gateway</octet-string>
<octet-string>COSEM logical name of the push setup object</octet-string>
<octet-string>COSEM logical name of event log</octet-string>
<array>
    <structure>event 1</structure>
    ...
    <structure>event n</structure>
</array>

The payload of the Data Notification APDU has the following structure for a meter logical device:

<octet-string>COSEM logical device name of the gateway</octet-string>
<octet-string>COSEM logical device name of the meter</octet-string>
<octet-string>COSEM logical name of the push setup object</octet-string>
<octet-string>COSEM logical name of event log</octet-string>
<octet-string>manufacturer ID</octet-string>
<integer>device type</integer>
<integer>firmware version</integer>
<array>
    <structure>event 1</structure>
    ...
    <structure>event n</structure>
</array>

Each event must contain the following items:

<octet-string>timestamp of the event</octet-string>
<octet-string>OBIS code of the event object</octet-string>
<unsigned>event code</unsigned>

Optionally, it may also contain another item:

<visible-string>custom event message</visible-string>

OBIS codes used:

Timestamp: 0.0.1.0.0.255

Event object: 0.0.96.11.0.255 (Standard), 0.0.96.11.1.255 (Fraud)

Custom event message: 0.128.96.11.0.255 (Standard), 0.128.96.11.1.255 (Fraud)

Event triggered push of data

Push On-Installation event

This event is triggered when the meter list of a gateway is changed. The event triggers a push with the event code On-Installation, which can be used by the HES to trigger a poll operation to update the meter list (read meter list from the gateway).

The gateway will only trigger a single push, even if more than one meter is added/removed during an operation. The hysteresis for grouping the event is three (3) minutes.

The payload of the Data Notification APDU has the following structure:

<octet-string>COSEM logical device name of the gateway</octet-string>
<octet-string>COSEM logical name of the push setup – on installation 
object</octet-string>
<double-long-unsigned>ip adress of the gateway</double-long-unsigned>
<octet-string> System title of the gateway as defined in IDIS Package 2 
IP profile Ed 2.0, section 6.1.1</octet-string>

The OBIS code for the push setup – on installation object is fixed to 0-7:25.9.0*255 (see IDIS Package 2 IP profile Ed 2.0, section 7.2.1).

Maintenance

Managing configurations

The product feature for managing configurations and backups also includes settings for DLMS Plugin (see “Manage configurations” section of the Product’s user interface).

As configuration files are used for duplicating settings between many devices, the DLMS password and keys are not part of the configuration file. They are however included in the backup file.

Saving a copy of the current configuration

The configuration contains all properties that can be edited in the Product. These can be used to duplicate configuration to several devices since they do not contain any device specific settings.

The file repository section now contains the newly created configuration file. This can then be used to update a device and/or revert erroneous configurations.

  1. Go to Configuration > Manage configurations.

  2. Choose Configuration as file type.

  3. Select Execute.

Importing a saved configuration

  1. Go to Configuration > Manage configurations.

  2. Select Choose File and choose the exported configuration file from the old device.

  3. Select Upload.

Reverting a configuration

  1. Go to Configuration > Manage configurations.

  2. Select the reload icon in the Action column of the configuration to revert to.

Managing backups

The backup contains configuration as well as a copy of the Products databases and operation system settings.

This backup contains device specific settings and is therefore not suitable for replicating configuration to another device, it should only be used to restore a device’s settings after a physical replacement.

Creating a backup

  1. Go to Configuration > Manage configurations.

  2. Choose Backup as file type.

  3. Select Execute

    The file repository section now contains the newly created backup file.

Replacing a device

  1. Create a backup of the configuration from the device that should be replaced.

  2. Import the backed up configuration to the replacement device.

Note

The system title of the replacement device will be new since it’s derived from the devices serial number. The HES might need to be updated accordingly.

Was this article helpful?

0 out of 0 found this helpful
Have more questions? Submit a request

Comments (0 comments)

Article is closed for comments.