See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/335433063

Building Advanced Metering Infrastructure using Elasticsearch Database and IEC

62056-21 Protocol

Conference Paper · August 2019

DOI: 10.1109/FiCloud.2019.00047

CITATIONS READS
3 6,052

1 author:

Marcin Bajer
ABB
30 PUBLICATIONS 144 CITATIONS

SEE PROFILE

All content following this page was uploaded by Marcin Bajer on 27 August 2019.

The user has requested enhancement of the downloaded file.

 Building Advanced Metering Infrastructure using
Elasticsearch database and IEC 62056-21 protocol
Marcin Bajer
ABB Corporate Research Center
Starowiślna 13a
31-038 Kraków, Poland
Email: marcin.bajer@pl.abb.com
Abstract—Building automation systems have been already
around for many years. Unfortunately, the still high cost of
smart building installation is difficult to justify for many non-
commercial applications such as residential buildings and houses.
The ongoing IoT revolution and popularization of low-cost ubiq-
uitous networking changes drastically the situation. Nowadays,
using off-the-shelf hardware and cloud based computing, it is
easier to provide to the end user the intelligent solution which
can be easily deployed and do not require significant building
refurbishment. Even partial implementation of smart building
concept will result in increase of energy efficiency as well as
comfort of building occupants. In this paper, the solution for
controlling and monitoring energy consumption in medium size
rent building (12 flats) is presented. The idea of the project
was to use ready-made, commercially available hardware and
extend its functionalities with custom software. In addition, the
Elasticsearch database was used to store energy usage data.
I. I NTRODUCTION
Important feature of modern Building Automation System
(BAS) is related with energy efficiency. Integration of energy
meters with Building Management System (BMS) can provide
real-time monitoring of building energy consumption. The
system can detect energy usage patters, historical building
energy performance can be logged and later utilized for total
energy use optimization. Also higher awareness of energy
consumption by the users can lead to lower overall energy
usage and have positive environmental impact [1].
II. H ISTORY OF MEASURING UTILITIES
Most of people are aware of presence of multiple meters
hidden somewhere in the basement, staircase or other out-
of-view location. One may even looked at it once every few
months to provide to the utility company the readings. Over
the recent years, a quiet revolution is taking place inside those
innocuous looking meters. Traditional mechanical meters are
being replaced by the electronic ones. More and more logic
and features is embedded inside each metering device. Par-
ticularly, looking at electricity meters, we can observe tree
generations of the meters:
Conventional meters It is the popularly known and most
common type of age-old meters. The measurement is based
on the use of mechanical counter mechanism very often com-
bined with gear trains and selected magnetic/electromagnetic
phenomenon. The counter allow to readout current state of one
or very limited number of measured physical quantities - i.e.
total water flow, total electricity usage. Reading of measured
data is not automated - each and every time direct access to
the meter is required to read it out.
AMR meters AMR stands for Automatic Meter Reading.
The era of ARM meters dates back to 1980s. Initially, the
trigger of their implementation was not related with labour
costs but to obtain data from locations with limited access (i.e.
where it is required to schedule meeting to obtain access to the
meter) [2]. In 1990s the advances in field of communication
technology (radio, power line and wireless based communi-
cations) allowed wider application of the idea. There are two
types of reading automation technologies [3]:
• mobile read systems, where data can be retrieved via short
range communication such as drive-by vehicle or walk-by
handheld system,
• fix network systems, where meter is connected directly
with the utility office via wired or wireless long-range
communication network.
Consequently, mobile read systems are much easier to deploy,
because they do not require any larger physical network. In
addition, very often conventional meters extended with battery
powered add-on module can be used. As the technology
has advanced, additional data could be captured, stored and
transferred, this can include more detail history of measured
value but also such events as tamper alarms, leak detections
or overconsumption.
All AMR systems have one important shortcoming - in most
cases, only communication from meter to the utility is possi-
ble. This one way communication model of communication
significantly limits AMR capability. In addition, data from
such systems is collected typically with monthly or, at most,
daily intervals [4]. AMR implementation reduces the labour
costs and enable more accurate billing, base on near real-
time consumption rather than on estimates, but does not
enable offering to customer dynamic pricing or any advanced
diagnostics or monitoring services.
AMI meters Advanced Metering Infrastructure (AMI) is the
next generation of metering systems. AMI meters, also known
as smart meters are updated, digital versions of the traditional
meters. AMI extends AMR by providing two way meter
 Communication
communications [5], typically is more automated than AMR Requirements
Smart Metering/Two- Advanced
and allows real-time, on-demand interrogations with metering Way Communications Smart

Conventional Electro-Mechanical
High Metering
endpoints. AMI is more complex than AMR and requires a

Meters/Manual Reading
• AMR (Automatic Meter
Reading)
large physical communication network [6]. While main goal
Automatic Meter Reading • Demand Response
of AMR implementation was remote reading of metering data, Medium (AMR)/One-Way
Communicaitons • Remote Connect/
in case of AMI this is only one of the features. Systems only Disconnect

capable of meter readings do not qualify as AMI system [2]. Support

Low
Smart
Bidirectional communication channel between meter and util- • Other Smart Metering Grid
Applicaiton Operation
ity’s back-haul network allows to send additional diagnostic No
communications
Prior to
and control information which can be use to detect and 1970
Prior to
2000
Prior to
2020
2020
Onwards
Year

prevent malfunctions. In addition, the data can be used to

optimize internal processes of utility operator such as assets
management, planing, engineering and operations.
The main trigger for development of AMI is energy metering
and integration of metering infrastructure into smart grids.
Cost-effective large-scale energy storage is out of reach so
energy production needs to exactly match energy consumption.
Daily and seasonal fluctuations in energy demand, growing
share of renewable energy sources in the energy mix and
increase in the popularity of electric cars, makes it even more
difficult. One of the ideas to balance the electricity market is
shaping energy consumption by dynamic pricing. In such case,
algorithms in smart appliances can automatically respond to
price drops and control household energy consumption. This,
so called, automatic demand response, requires AMI imple-
mentation to charge customers based on actual energy price.
With such approach, on one hand, consumers can save money
by running power hungry devices during off-peak periods
and, on the other hand, utility companies can avoid building
additional infrastructure and generation units to meet demand
during peak period. In addition, AMI can be used to control
renewable energy sources such as PV installations or wind
farms. In critical situations, grid operator can remotely switch
off such installation to prevent grid malfunction. Advanced
metering infrastructure adaptation it the first step towards
building the true smart grid which will evolve in the future
to meet future demands (Figure 1).
III. AMI IMPLEMENTATION BARRIERS
To fully utilize AMI capabilities and implement demand
response, connection with devices installed inside local home
area network (HAN) is required. This can be done directly
by HAN devices or through dedicated Energy Management
System (EMS). In both cases, AMI data is useful to effi-
ciently control building equipment (EV charger, PV or HVAC
installation) and smart home appliances (thermostats, washing
machines, clothes dryers, refrigerators). Unfortunately, there is
no common standard for communication within HAM. In fact,
multiple, both wired and wireless, communication protocols
are in use. Smart building equipment need to deal with various
constraints such as energy usage, security, limited computation
power and many others, therefore it is difficult to achieve
interoperability. In addition, devices installed in a building of-
ten comes from different industries each promoting own stan-
dard (lighting - DALI, metering - IEC 62056/M-Bus, HVAC -
Opentherm/BACnet, industrial equipment - Modbus/OPC) [9].
Fig. 1. Evolution of electricity metering [7]
Nowadays, with the growing popularity of smart sensors
and IoT devices, wireless protocols such as Bluetooth Low
Energy, ZigBee, Thread or Z-Wave also noticeably gain greater
acceptance.
Another problem is missing consistent standards for demand
response (DR) control signals, which would allow both cus-
tomers and grid operator to take full advantage of integration
intermittent energy sources and dynamic pricing. One of the
very first approaches to address this issue was related with
development of Open Automated Demand Response Com-
munications Specification which is also know as OpenADR.
OpenADR is an open, highly secure, and two-way information
exchange model and Smart Grid standard which addresses
challenges related both with Demand Response control as well
as with managing distributed energy sources. The goal is to
standardize fully automated system which allows interactions
between price signals from the utility and customer’s precon-
figured EMS system [10].
IV. AMI E LEMENTS
An AMI system use a multi-layer communications architec-
ture which is based on three major components: Meter Data
Management System, Data Concentrators and Smart Meters
(Figure 2).
Meter Data Management System (MDMS) is a central
database designed to store and manage data collected from the
meters. Typically it also provides services such as cleansing,
validation and aggregation of consumption and event data
obtained from meters installed on delivery points to furnish
customer service and system operation with calculations such
as billing, demand forecasting or asset management.
Data concentrators (also known as data collectors or data
aggregation units [8]) have responsibility to forward data col-
lected from smart meters further on its path to central utility
database. Data concentrators are usually located at the edges
of Neighbourhood Area Networks (NAN). They are used to
interconnect NAN which commonly use low bandwidth radio
frequency or power line communication with high throughput
Wide Area Network (WAN) used for communication with
Meter Data Management System.
 Utility System Communication Reader Meter
(Service Provider) Module

Initialization
Mater Data
Smart Meter
Management Washing 300 baud
(Gas, Water, HVAC Hot Water
System Machine Request
Electricity)
(MDMS)
Identity

Data Communication Energy Management Washer & Acknowledge

Concentrator Module System (EMS) Dryer
Data readout
AMI System

Vacuum N baud
TV Fire alarm
Cleaner Start character

Smart Home & Building Automation System Parameter 1

...
Fig. 2. AMI System Diagram [11] Parameter N

Ending sequence

Smart Meters are key components of AMI. They are able Fig. 3. IEC 61107 Protocol mode C data readout diagram
to both communicate consumption data as well as to receive
configuration.
TABLE I
All those elements are located in various networks and dif- IEC 61107 P ROTOCOL TELEGRAM TYPES
ferent realms, but reliable realtime communication between
them is critical. Basically, two types of information infras- Request → / ? Device address (optional) ! CR LF
tructure are needed to provide information flow. First, building ← Identity / X X X Z Identification CR LF
equipment and electrical appliances need to communicate with Acknowledge → ACK V Z Y CR LF
smart meters. Second, smart meters and the utility’s data ← Data readout STX Data block ! CR LF ETX BCC
centers needs to be interconnected via secure data channel [12].

V. IEC 62056 S TANDARDS
Standards regarding AMI are still emerging. IEC 62056 is
one of the most widely accepted specifications for AMI data
exchange in Europe. In fact, it is a series of documents which
define various methods for meter reading, tariffs notification
and load control. It is based on DLMS (Device Language
Message Specification) protocol and COSEM (Companion
Specification for the Energy Metering) model. DLMS is com-
parable to the set of rules or the common language, which
standardize the communication protocol, the data objects
and object codes [13]. COSEM provides information about
Transport and Application Layers for the DLMS protocol.
To abstract various aspects of metering data, it specifies
multiple object classes with their attributes and methods of
modification. OBIS (Object Identification System) naming is
used to identify COSEM objects to make them self-describing.
DLMS/COSEM protocol is not limited to electricity metering,
it can be also used for water, gas and heat metering.
VI. IEC 62056-21 PROTOCOL
IEC 62056 supersedes IEC 61107 - older, commonly used,
communication standard to read utility meters, which was
designed on top of, so called, FLAG protocol. Currently,
IEC 61107 is incorporated into IEC 62056 as IEC 62056-21.
IEC 61107 is relatively simple, half-duplex, ASCII based (in
mode E binary data might be transferred), protocol. Although,
it can easily operate over any media, including the Internet,
the communication with the meter is usually done via serial
port where physical media is either simple short range optical
link (two pairs of phototransistor and infrared emitter), 20mA
current loop (RS-485) or ±15V voltage signal (RS-232).
The IEC 62056-21 compliant meter can implement up to
five communication modes – A, B, C, D and E. Modes A to
C use bidirectrional master (reader) - slave (meter) communica-
tion. In protocol mode D transmission is unidirectional, data
communication is initiated by trigger - i.e. button press. Mode
E is designed to implement client (reader) - server (meter) ar-
chitecture and allows binary data transfer with High-Level
Data Link Control (HDLC).
For electricity meters, protocol version C is commonly used
(Figure 3, Tables I and II). Default communication is 300 baud,
7 data bits with single start and stop bit. First part of data
exchange involves initialization and changing the transmission
speed. Each telegram is concluded with Windows line ending
(CR+LF). The communication starts with Request telegram
which might contain up to 32 characters Device address field.
If no address is specified, all devices try to answer back send-
ing their identity. The identity telegram contains 3 characters
code of the meter manufacturer (represented by XXX), one
character to identify supported baudrates (Z field) and meter
identification. To trigger data readout from the meter, reader
sends Acknowledge which contains baudrate control (Z) and
selection between data readout mode and programming mode
(Y). If data readout mode is selected, meter indicate start of
sending data (STX character) and promulgate most important
metering data. Each COSEM object is transmitted as a single
line which contains object OBIS code and value. The ending
sequence contains transmission end character (ETX) and one
byte of block check character (BCC) to ensure data block
integrity.
Each parameter in data block is send as a separate line, the
content is composed according to the IEC 62056-61 standard.
To match content of the line with particular data items regis-
tered by the meter, understanding of OBIS codes is required.
The code consists of (up to) 6 group sub-identifiers marked
by letters A to F (Figure 4). All these do not need to be
 Energy Optical
TABLE II meter probe
USB
C OMMUNICATION WITH PAFAL 16EC3 GR METER
Energy Optical
meter probe USB
Router
USB
Energy Optical OpenWRT
Dir Ascii Hex meter probe Webpage
Ser2net
→ /?!.. 2f 3f 21 0d 0a HTTP
Node.js/AngularJS

← /PAF5EC3rn-20900.. 2f 50 41 46 35 45 43 33 72 6e 2d 32 30 39 30 30 0d 0a ⦙ ⦙
Database
→ .150.. 06 31 35 30 0d 0a HTTP
HTTP
Kibana
IEC 62056-21 Elasticsearch
Baudrate change to 9600 bauds Router
⦙ Ser2net Datacollector
OpenWRT
← .0.0.0(71945766).. 02 30 2e 30 2e 30 28 37 31 39 34 35 37 36 36 29 0d 0a Python
TCP

MQTT server Control logic

← 0.0.1(PAF).. 30 2e 30 2e 31 28 50 41 46 29 0d 0a Ser2net
TCP
Mosquitto NodeRED
.. .. ⦙
⦙
← . .
← 15.7.0(00.0010)!...¡ 31 35 2e 37 2e 30 28 30 30 2e 30 30 31 30 29 21 0d 0a 03 3c Router
Energy
meter
Optical
probe
USB
⦙
USB OpenWRT

Energy Optical
meter probe
Medium Channel Type Variable Tariff Period

Fig. 5. Data flow in prepared AMI system

A - B : C . D . E * F ( Value )
15 . 8 . 2 * 01 ( 001144.15 )

the future, historical AMI data can be used to examine the

Electricity 1 Active Energy Tarrif T2 Last closed profitability and select the most optimal configuration PV
or solar installation. In addition, while integrated with smart
Fig. 4. OBIS code for Absolute active energy (A+) tariff T2 in last closed building installation, realtime AMI data can be used to control
billing period.
usage of PV energy to maximize captive consumption.

present in the identifier - groups A and B are often omitted. In
order to decide to which group the sub-identifier belongs, the
groups are separated by unique separators. Thousands of OBIS
codes have been defined, they cover metering data as well as
configuration of metering equipment and meter status for all
types of utility metering applications including: electricity, gas,
heat and water.
VII. P REPARED AMI SYSTEM
In the following section, an implementation example of
a simple AMI system based on the IEC 62056-61 standard
will be described. The system was installed in a three-storey
tenement building. The building was recently renovated, which
included the transfer of all utility meters from the apartments
to the staircase and implementation of central heating and cen-
tral hot water installations. To provide the WiFi coverage on
each floor two access points, made out of off-the-shelf SOHO
class router with USB interface (i.e. TP-Link TL-WDR4300
or TP-Link Archer C7), were installed. The factory firmware
was replaced by custom compiled OpenWRT [14]. The goal
was to use resources on the routers not only as elements of IT
network, but also as elements of smart building installation.
Both the CPU load and memory usage are neglectable, because
in most cases the routers works only in Access Point (AP)
mode, without any routing between sub-networks.
Although, the main functionality of AMI systems is related
with automatic demand response and billing base on the
realtime usage - this can not be done without strict cooperation
with utility provider - there are still many advantages of
installing custom AMI system. First of all, AMI system allows
to monitor energy usage in realtime and identify potential
savings and malfunctions. Second, since the flats are often
rented, AMI system reduce overhead related with re-invoicing
utility costs, by building administration - with AMI it can
be done in a fully automated fashion. Third, potentially in
VIII. S YSTEM COMPONENTS
The overall AMI system was described in Figure 5. It is
based on four major components:
IEC 62056-21 compliant meters - 16 meters, provided by
the utility company (two types: Pafal EC3 and Pafal EA52). It
was found that those meters provide much more data than just
overall energy usage and instantaneous energy consumption.
For each closed metering period (length to be set during
meter commissioning - usually one month) values such as
overall energy consumption and maximal energy demand are
being stored. In addition, those meters provide the information
about instantaneous voltages and currents for each phase.
Unfortunately, for those types of meters information such as
THD or reactive power are not available.
Optical probes - there are multiple providers of optical heads
compatible with IEC 62056-21 standard. Although, the circuit
is relatively simple and based on cheap components, the
solutions available on the market, are quite expensive (approx.
40 EUR per unit). To reduce the costs of overall system,
the simplified solution can be used. It is based on easy to
find in the Internet and cheap USB↔UART converters (less
than 1 EUR per piece), missing part is the housing and IR
send/receive part of the circuit. In many cases USB↔UART
converters have already terminals protected by resistors against
the overload - this means it is enough to connect IR diode
and photo-transistor to provide fully functional IR probe
(Figure 6A). Unfortunately, such solution not always provide
the required power of the broadcast signal, therefore the trans-
mitting unit has been equipped with a transistor to drive IR
diode current (Figure 6B). Presented solution works quite well
with slow transmission speed (up to 2400 bauds), to increase
the supported baudrate and reduce number of communication
errors, it is required to make receiving part of the circuit more
sensitive (Figure 6C).

Fig. 6. IEC 62056-21 optical probe schematic (base on [15])
Routers - Each APs installed in the building is regular Linux
based system. To some extend, most of the command line tools
available in desktop Linux can be also available on network
routers. The first idea was to use APs as transparent gateways
between optical probes connected to USB ports and a data
collector device. First approach was to share USB device over
IP network. Linux provides dedicated tools for this - usbip-
server/usbip-client which encapsulates ”USB I/O messages”
inside TCP/IP telegrams and transmits them between paired
devices. In the end, this allowed to see all USB↔UART
converters as a regular tty ports on the data collector device.
Although, the solution worked, the connection was not always
stable. It turn out to that more reliable was to use raw UDP
connection to tunnel telegrams send between meter and the
data collector. Also in this case suitable Linux tool - ser2net
- has been found. The tool is serial port to network proxy,
which allows to establish remote telnet or TCP sessions to
configured serial ports. It can be configured statically via
config file and dynamically via config port which allows to
telnet new configuration using simple interface.
Older versions of Linux kernel contains bug in imple-
mentation of driver for handling CH340 USB↔UART
converters which does not allow to set 7-bits transmis-
sion required for IEC 62056-21 communication [16].
Data collectors - The main logic of the system has been
included in the data collectors. In presented installation
the data collector was running smoothly on RaspberryPi 3
(1,4GHz quad-core ARM-8 Cortex-A53 with 1GB DDR2
RAM). Python application which was lunched on this device
was responsible for initialization of communication with the
meters and transcoding content of metering data send by the
meter. Using regex expression, the content of the each line in
divided into particular subelements - OBIS code sub-identifiers
and value. Later, meaning of the OBIS code is decoded. Each
metering parameter is stored separately in the database, but
the commit to the database is done as a batch when calculated
CRC (BCC) is correct.
Database - As a database Elasticsearch has been used. Al-
though, it requires decent hardware (especially in case of
required amount of RAM) it has been already proven as the
good engine for storing IoT data [17]. Elasticsearch is schema-
less database with powerful REST API - it is sufficient to
April 7th 2019, 20:48:17.687 description: This billing period. Absolute active energy (A+) total [kWh] hour: 18 timestamp: April 7th 2019, 20:48:17.687 float: 6,240.09
parameter: 15.8.0*00 weekday: 6 _id: Hcch-WkBcDZYcBK-OPAY _type: electricity _index: electricity-2019-04-07 _score: - location: Apartament 1
Table JSON View surrounding documents View single document
_id Hcch-WkBcDZYcBK-OPAY
t
_index electricity-2019-04-07
t
_score -
#
_type electricity
t
description This billing period. Absolute active energy (A+) total [kWh]
t
float 6,240.09
#
hour 18
t
location Apartament 1
t
parameter 15.8.0*00
t
timestamp April 7th 2019, 20:48:17.687
weekday 6
t
Fig. 7. Single parameter entry in Kibana
send JSON object via HTTP API and entry, with appropriate
mapping for each JSON field, automatically will be created.
Elasticsearch provides also, out of the box, horizontal scaling
and data resiliency. The engine will manage automatically
distribute both the data queries as well as the data itself over
distributed nodes.
The key to efficiency use Elasticsearch as a database for
IoT is to enforce suitable mapping of the entries stored in
particular indexes. By default, Elasticsearch will map string
type data both as a keyword and as a text - this means every
single word from the string field will be indexed separately
to allow full text search. In most cases, for IoT data, this is
not needed. To allow fix mapping of types in the database,
value type of each metering parameter is detected by the data
collector and encoded as JSON element named after the type
of the data: float - floating point number, int - for decimals, str -
for keywords (Listening 1). To reduce the number of data in
the database, a data collector keeps the values related with
each OBIS code and save to the database only the changed
parameters. In addition, to speed-up data aggregation, each
entry in the database contains additional fields: hour and
weekday (Figure 7).
{” t e m p l a t e ” : ” e l e c t r i c i t y ∗” ,
” mappings ” :{ ” e l e c t r i c i t y ” :{ ” p r o p e r t i e s ” :{
” @ v e r s i o n ” : { ” t y p e ” : ” keyword ” } ,
” d e s c r i p t i o n ” : { ” t y p e ” : ” keyword ” } ,
” d e t a i l ” : { ” t y p e ” : ” keyword ” } ,
” f l o a t ” :{ ” type ” : ” f l o a t ” } ,
” i n t ” :{ ” type ” : ” long ” } ,
” l o c a t i o n ” : { ” t y p e ” : ” keyword ” } ,
” p a r a m e t e r ” : { ” t y p e ” : ” keyword ” } ,
” s t r ” : { ” t y p e ” : ” keyword ” } ,
” timestamp ” :{ ” type ” : ” date ” } ,
” u n i t ” : { ” t y p e ” : ” keyword ” } ,
” weekday ” : { ” t y p e ” : ” keyword ” } ,
” h o u r ” : { ” t y p e ” : ” keyword ” }
}}}}
Listing 1. Elasticsearch mapping template for single metering parameter
Kibana - Kibana is a visualization platform for Elasticsearch
which provides web-based interface for search, view and
analyse data stored in Elasticsearch. Besides showing raw
database entries, it also allows to easy visualize the data
with various types of charts. Recent versions, also provides
basic functions for cluster health monitoring or unsupervised
machine learning. Unfortunately, still, some high-end features,
such as role-based access control, are not available in open
source version of Kibana. The data stored in Elastisearch can
be visualized in 3 different views: Discover provides access to
 steps, prepared system should be extended with capability
of reading water and heat meters. Coupling energy usage
with other utilities could give more meaningful insight about
what events are taking place in the building. Also deeper
integration with current building automation system would
be desired. Currently, all AMI data as well as the data from
movement sensors and light control system is available by
the MQTT server, but it is not used to perform any control
New Add Save Delete Open Options Help  Auto-refresh 
actions or automatic alarm triggering - i.e. the tenant should
 May 12th 2019, 04:16:13.333 to May 12th 2019, 12:39:00.000 

be notified in case of significant energy usage in the flat when

.es(q='location:"Mieszkanie 12" AND parameter:"15.7.0"', index=electricity-*,metric=avg: oat).mvavg(10min).points(symbol=cross, radius=2).label("Energy usage - moving averadge 10min"), .es(q='location:"Mieszkanie 12" AND parameter:"15.7.0"', index=electricity-*,metric=avg: oat).mvavg(30min).label("Energy usage - auto
moving averadge 30min").legend(columns=2, position=sw)

0.40
no human movement is detected because this can indicate that


the stovetop was left on unattended.

0.35

To some extend presented solution is comparable to AMI

Fig. 8. Heatmap - energy usage per hour of day
0.30 system diagram provided in Figure 2 where Python based data
0.25
collector is equivalent of data concentrator and Elasticsearch
database refers to Meter Data Management System.
0.20

Although, this was not tested, the prepared system seems to

0.15
be easily scalable - each layer presented in the Figure 5 can be
scaled horizontally by adding required number of components
0.10

to achieve required overall system performance.

0.05

R EFERENCES
Energy usage - moving averadge 10min Energy usage - moving averadge 30min
0.00
04:30 05:00 05:30 06:00 06:30 07:00 07:30 08:00 08:30 09:00 09:30 10:00 10:30 11:00 11:30 12:00 12:30

[1] Georgiou A, Ioannou P., Christodoulides P., Domestic Electricity Con-

sumption and the Public Awareness Factor, 4th International Conference
Fig. 9. Timelion - Refrigerator energy usage pattern on Renewable Energy Sources and Energy Efficiency - New Challenges,
Nicosia Cyprus, 6-7 June 2013
[2] Huang Q., Jing S., Zhen W., Yi J., Innovative Testing and Measurement
raw database entries in a tabular form. The data can be easily Solutions for Smart Grid, John Wiley&Sons, 2016, pp. 151
[3] Phys M., Crainic, M.,A Short history of residential water meters part III
filtered and searched by time or by entry properties using improvements of water meters. Installations for Buildings and Ambiental
D

Apache Lucene query syntax. Visualize allows to show present Comfort Conference XXI, Timisoara Romania 18-20 April 2012, pp. 44-
data with one of provided visualization plugins. Information 52
[4] Ten C.W., Tang Y., Electric Power: Distribution Emergency Operation,
can be shown, among others, in form of charts, maps, his- 2018, CRC Press,
tograms or heatmaps (i.e. Figure 8). In addition, timeseries data [5] Huang Q., Jing S., Yi, J., Zhen, W., Innovative Testing and Measurement
can be visualized with dedicated tool - Timelion that enables Solutions for Smart Grid, Wiley, 2015, pp. 151
[6] Hawkins Ch., Berthold A., Considerations for adopting AMI and AMR,
user to combine totally independent data sources within a Texas Water Resources Insitute, 2015, pp. 4
single visualization. With Timelion, using relatively simple, [7] Ekanayake J.B., Jenkins N., Liyanage K., Wu J., Yokoyama A., Smart
dedicated language, one can generate sophisticated plots which Grid: Technology and Applications, Wiley, 2012, pp. 84
[8] Bush S.F., Smart Grid: Communication-Enabled Intelligence for the
involves execution of advanced mathematical operations on the Electric Power Grid, Wiley 2014, pp. 240
data in advance (i.e. Figure 9). In the end various visualizations [9] Bajer M., IoT for Smart Buildings - Long Awaited Revolution or Lean
can be placed on one common Dashboard to allow users high Evolution, 2018 IEEE 6th International Conference on Future Internet of
Things and Cloud (FiCloud), Barcelona, 2018, pp. 149-154.
level view of energy usage in the building. [10] Bush S. F., Smart Grid: Communication-Enabled Intelligence for the
Unfortunately, due to the poor support of rule based access to Electric Power Grid, John Wiley&Sons, 2014, pp. 244.
the Elasticsearch/Kibana based systems (at least in the open [11] Sato T., Kammen D.M., Duan B., Macuha M., Zhou Z., Wu J., Tariq
M., Asfaw, S.A., Smart Grid Standards: Specifications, Requirements, and
source version) alternative system with Node.js/Angularjs has Technologies, Wiley, 2015, pp. 191
been prepared. The main purpose of this system is to provide [12] Gungor V. C., Sahin D., Kocak T., Ergüt S., Buccella C., Cecati C.,
flat tenants access to the energy usage data. Only, some really Hancke G. P.,Smart Grid Technologies: Communication Technologies and
Standards, IEEE Transactions on Industrial Informatics, 2011
basic statistics are being shown now, but this is to be changed [13] Sato T., Kammen D.M., Duan B., Macuha M., Zhou Z., Wu J., Tariq
in later versions. In addition, this system shows also monthly M., Asfaw S.A., Smart Grid Standards: Specifications, Requirements, and
bills, which include also costs of other utilities (water, heat), Technologies, Wiley, 2015, pp. 191
[14] OpenWRT project webpage, https://openwrt.org
calculated base on manual readings of the meters. [15] CH340G USB to RS232 TTL module schematic, http://nicecircuits.com/
ch340g-usb-to-rs232-ttl-module-schematic-d-sun-v3-0
IX. S UMMARY [16] Linux Kernel repository commits, https://git.kernel.org/pub/scm/
linux/kernel/git/torvalds//linux.git/commit/drivers/usb/serial/ch341.c?id=
In presented paper, custom made AMI system has been 7c61b0d5e82bfe29b8dda55745afbf65b6ccc901
prepared. Although it provides only a part of the features [17] Bajer M., Building an IoT Data Hub with Elasticsearch, Logstash and
Kibana, 2017 IEEE 5th International Conference on Future Internet of
of classical AMI system, it has been already proven for Things and Cloud (FiCloud), Prague, 2017, pp. 63–68
the building administration as very useful both to realize
their daily tasks and detect potential anomalies. In further

View publication stats