CMe3100 DLMS Plugin
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 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 objects, channel selections 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 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.
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.
The installation of the plugin is done by uploading a license file and activating the license.
-
Log in to the web interface.
-
Go to System>Licenses.
-
Select Choose file in the Upload new licenses section.
-
Locate the license file you want to upload.
-
Select Upload.
-
Select Save.
The license is now visible in the Current license (s) window.
-
Select System> Reboot device to finalize the installation of the plugin.
Note
Important! Reboot the CMe3100 in order to start using the BACnet plugin.
-
Go to the DLMS Plugin settings. The settings can be accessed in two ways:
-
Go to Configuration > Services > DLMS.
-
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.
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 product enables poll/push operation of three different generic profiles; Load profile 1, Load profile 2, Billing profile
All three profiles can be configured individually to allow maximum flexibility regarding what value interval that is of interest.
-
Go to Configuration > Services > DLMS > Settings.
-
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.
-
-
Select Save to store the changes.
The product supports security site 0 with none, low level or high level security.
-
Go to Configuration > Services > DLMS > Settings.
-
Select a value for Security policy.
-
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.
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.
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 specific 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 does not 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 do not support some of the M-Bus keys specified in the meter mapping file.
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.
This section shows available/installed meters in the product. By clicking at 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.
-
Go to Configuration > Services > DLMS > OBIS meter mapping.
-
Download template file.
-
To create a new meter mapping file, download it in Meter types in use section.
-
To modify an existing meter mapping file, download it in Actie meter mappings section.
-
-
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 created 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 handle, for example, meters which have 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.
-
Matching type, manufacturer, and version.
-
Matching type, manufacturer, and generic version.
-
Matching type, generic manufacturer, and generic version.
Meter mapping file example
The previous example file matches all water meters and does not consider the manufacturer or the 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 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:
-
Retrieving raw M-bus data.
-
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 121. 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 |
-
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.
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
}
...
-
Map an OBIS code to mbus.telegram.decoded.value for M-bus values.
-
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.
#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
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
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
},
...
Note
By default, all OBIS codes included in a mapping file will be included in all Push Reports for matching meters.
Table 122. 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 123. 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] |
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.
-
Go to Configuration > Push Reports > DLMS settings.
-
Enable or disable the push notifications.
-
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.
-
To disable, clear the checkbox for Push notification when meter list changed.
-
-
Go to Configuration > Push Reports > DLMS settings.
-
Enter the default server address (IP or hostname) in the Default address field.
-
Enter the TCP port to be used when sending Push Reports in the Port field.
-
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.
-
Select or clear the checkbox for Encrypt communication to enable or disable.
-
Go to Configuration > Push Reports and select the report in the list you want to configure.
-
Select DLMS in the Report type dropdown menu.
-
Select a profile in Report template dropdown menu.
-
To configure Push Report of load profile/billing profile, select 9010 (Load profile1), 9011 (Load profile 2) or 9012 (Billing profile).
-
To configure Push Report of standard event log, select 9001 (Standard event log).
-
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.
-
-
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.
-
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.
-
Select the checkbox for Send report to default DLMS server to use the default server settings for DLMS servers that receive the Push Report.
-
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.
-
Enter Backup address and Port to use a fallback server if the report fails when sending report to the default address.
-
To trigger a test report, select Save and Send test report.
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
-
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)
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):
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.
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.
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).
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.
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 124, “Encryption keys description” for more information about the keys and their usage.
Table 124. 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.
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.
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 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>
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.
Following COSEM objects are available in the management logical device:
|
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 object can be read from the gateway to identify available logical devices.
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.
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
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.
Data type: long-unsigned
This object enables switching between all logical devices during a single association.
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>
Data type: octet-string
This object holds the gateway firmware version information.
Data type: octet-string
This object holds the gateway firmware signature information.
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.
Data type: long-unsigned
This object holds the event id of the last event logged to Standard Event Log.
Data type: visible-string
This object holds the event description of the last event logged to Standard Event Log.
Data type: long-unsigned
This object holds the event id of the last event logged to Fraud Event Log.
Data type: visible-string
This object holds the event description of the last event logged to Fraud Event Log.
Data type: octet-string
This object is used for testing and it should be ignored. It does not hold any information.
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:
-
Logical name
-
Buffer (actual data)
Selector 0 (all data) and selector 1(from-to) implemented
-
Capture objects (list of OBIS codes)
-
N/A
-
N/A
-
N/A
-
Entries in use in the database
-
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.
The push setup object holds the information about the objects to be included in the Standard Event Log Push report.
The push setup object holds the information about the objects to be included in the Fraud Event Log Push report.
The push setup object holds the information about the objects to be included in the On Installation Event Push report.
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), section 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.
Following COSEM objects are available in each meter logical device:
|
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 object can be read from the gateway to identify available logical devices.
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.
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.
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.
Data type: long-unsigned
This object enables switching between all logical devices during a single association.
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.
Data type: octet-string
This object holds the meter firmware version information.
Data type: octet-string
This object holds the meter manufacturer id information.
Data type: long-unsigned
This object holds the event id of the last event logged to Standard Event Log.
Data type: visible-string
This object holds the event description of the last event logged to Standard Event Log.
Data type: long-unsigned
This object holds the event id of the last event logged to Fraud Event Log.
Data type: visible-string
This object holds the event description of the last event logged to Fraud Event Log.
Data type: octet-string
This object is used for testing and it should be ignored. It doesn’t hold any information.
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:
-
Logical name
-
Buffer (actual data)
Selector 0 (all data) and selector 1(from-to) implemented
-
Capture objects (list of OBIS codes)
-
N/A
-
N/A
-
N/A
-
Entries in use in the database
-
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.
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:
-
Logical name
-
Buffer (actual data)
Selector 0 (all data) and selector 1(from-to) implemented
-
Capture objects (list of OBIS codes)
-
N/A
-
N/A
-
N/A
-
Entries in use in the database
-
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.
The push setup object holds the information about the objects to be included in the Load Profile 1 Push report.
The push setup object holds the information about the objects to be included in the Load Profile 2 Push report
The push setup object holds the information about the objects to be included in the Billing Data Push report.
The push setup object holds the information about the objects to be included in the Standard Event Log Push report.
The push setup object holds the information about the objects to be included in the Fraud Event Log Push report.
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.
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.
The gateway supports to push data periodically or push data on events.
Push notifications are sent using Data-Notification-Service.
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
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)
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).
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.
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 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.
Comments (0 comments)