Wireless M-Bus in Industrial IoT: Technology

European Wireless 2017

Wireless M-Bus in Industrial IoT: Technology Overview and Prototype Implementation Krystof Zeman1 , Pavel Masek1 , Jan Krejci1 , Aleksandr Ometov2,3 , Jiri Hosek1 , Sergey Andreev2 , and Franz Kr¨opfl4 1 Brno University of Technology, Department of Telecommunications, Brno, Czech Republic 2 Tampere University of Technology, Department of Electronics and Communications Engineering, Tampere, Finland 3 Peoples’ Friendship University of Russia (RUDN University), 6 Miklukho-Maklaya St, Moscow, 117198, Russian Federation 4 Telekom Austria Group, Lassallestraße 9, A-1020, Wien, Austria Contact author’s e-mail: [email protected] maintenance of devices, where cost reductions can reach up to 12% over scheduled repairs, also mitigating the breakdowns by up to 70% [7].

Abstract—During the past 15 years, the Internet revolution has redefined the industry landscape. The advent of the Internet of Things (IoT) is changing our lives by provisioning a wide range of novel applications that leverage the ecosystem of “smart” and highly heterogeneous devices. This is expected to dramatically transform manufacturing, energy, agriculture, transportation, and other industrial sectors. The Industrial Internet of Things (IIoT) brings along a new wave of Internet evolution and will offer unprecedented opportunities in Machine Type Communications (MTC) – intelligent industrial products, processes, and services that communicate with each other and with people over the global network. This paper delivers a technology overview of the currently utilized Wireless M-Bus communication protocol within the IIoT landscape together with describing a demonstration prototype development. In our trial implementation, the IQRF modules are utilized to be compatible with the protocol of interest. The constructed WM-Bus receiver is further integrated as part of a complex MTC Gateway, which receives the MTC data via a secure communication channel from various types of smart-metering devices.

Advances in Predictive Maintenance ... 3. Outcome Economy

- Continuous demand-sensing - End-to-end automation - Resource optimization

- Pay-per-outcome

2. New Products - New connected ecosystems - Platform-enabled marketplace & Services 1. Operational - Pay-per-use - Software-based services Efficiency - Data monetization - Asset utilization - Operational cost reduction - Worker productivity

within Industrial IoT Landscape

Fig. 1. Adoption and impact path of the Industrial Internet of Things.

There are many early adopters, such as Caterpillar, ThyssenKrup, and Thames Water, already implementing and benefiting from the IIoT. Here, Caterpillar Marine [8] is utilizing predictive maintenance to reduce costs of ships upkeep (i.e., hull cleaning)2 . Thames water, the largest provider of water and waste-water services in the United Kingdom, is using realtime-data analytics from sensors to anticipate equipment failures and respond faster to critical situations3 . Another good example is Apache corporation, an oil&gas exploration and production company, which is using predictive maintenance to forecast onshore and offshore oil pump failures thus maximizing the production. Apache claims that if the global oil industry improves pump performance by only one percent, the daily production of oil will increase by 500 thousand of barrels, hence generating an additional $19 billion per year [9].

I. I NTRODUCTION Today, the Industrial Internet of Things (IIoT) is gaining popularity by having a significant impact on the global economy [1], [2], [3]. According to the Oxford Economics, it represents 62% of gross domestic product in the G20 countries. It encompasses not only manufacturing, agriculture, oil, gas, and mining companies, but also organizations that offer logistic and healthcare services1 . According to the most conservative estimates, the revenue of the IIoT will reach $500 billion by 2020, see Fig. 1. More optimistic predictions expect about $15 billion of global Gross Domestic Product (GDP) by 2030 [4]. The IIoT pioneers mostly focus on the operational efficiency [5]. Due to improvements in production techniques and introduction of automation, productivity can be boosted by up to 30%, which e.g., in Germany means a boost in the cumulative gross value (across all industry areas) of e267 billion by 2025 [6]. Another point of interest is in predictive

2 See Caterpillar Marine Asset Intelligence, Caterpillar Marine Asset Intelligence, 2016: http://www.cat.com/en US/news/engine-press-releases/ 3 See Accenture to Help Thames Water Prove the Benefits of Smart Monitoring Capabilities, World Economics Forum, 2014: http://reports.weforum.org/industrial-internet-of-things/general-findings/ 2-3-key-near-term-opportunities-and-benefits/

1 See Global Industry Databank Forecasts, by Oxford Economics, 2015: https://www.oxfordeconomics.com/forecasts-and-models/industries/ data-and-forecasts/global-industry-databank/overview

ISBN 978-3-8007-4426-8

4. Autonomous, Pull Economy

40

© VDE VERLAG GMBH ∙ Berlin ∙ Offenbach


WM-Bus

IPv4/IPv6

Proprietary

aHTTP, RESTa

MQTT

AMQP

mDNS

II OT

DNS-SD RLP

6LoWPAN

IEEE 802.15.4, IEEE 802.11, IEEE 802.3 LTE-A; NB-IoT

EPC Global

IEEE 802.15.4

Z-Wave

IMS

battery-powered device to autonomously operate for up to 10 years. This requirement can be achieved if the radio management module is switched to the low-power mode for as long as possible, and hence the awakening and transmitting procedures are managed and optimized. Based on the standard, the communication initiation node is always the smart meter and never the concentrator, which is more suitable to extend the lifespan of the sensor battery. The WM-Bus network topology is a star, where one or more measuring nodes transmit(s) the data to the aggregator acting as a server. The latter always senses the wireless medium for incoming connections and subsequent data collection. WMBus provides six communication modes representing specific applications detailed in Table II. First three modes (i.e., S, T , and R) correspond to the transfer speeds, which are further divided into modes 1 and 2 for unidirectional or bidirectional communication. The other three modes (i.e., N , C, and F ) are supported only by specific devices: • In frequent transmit mode (T ), the meter sends data periodically or whenever a packet is available. Sub-mode T 1 defines power saving operation, in which the device transmits to the aggregator and immediately enters power saving mode without waiting for the ACK. • Stationary mode (S) is designed for unidirectional or bidirectional communication between the stationary or mobile devices. It has three sub-modes, S1, S1M , and S2. Sub-mode S1 is for unidirectional communication without the ACK from a server. This mode is primarily to handle the “daily” data transmissions. Sub-mode S1M supports bidirectional communication in predefined cycles without the need for the device to wake up. • In frequent receive mode (R), the meter is not sending the data periodically but instead is waiting for the aggregation request. Most of the time, the meter is in the power saving mode and awakens only over the predefined intervals for the packet reception. If no valid wake-up frame is received, the meter reenters the power saving mode. The MTC between the WM-Bus equipped devices provides the application developers with certain flexibility to configure the devices. Therefore, the communication process may be optimized subject to the scenario and/or the client request.

II. MTC IN I NDUSTRIAL I OT Following the concept of IIoT, devices are equipped with the communication modules (primarily, wireless) and referred to as Machine Type Communications (MTC) [12]. Furthermore, data collected from the smart devices needs to be delivered and stored at the aggregation node, as well as periodically forwarded to the cloud server [11]. This concept has sparked development of many IoT standards and recommendations within different development groups and standardization initiatives. Table I provides a summary of the most prominent protocols e.g., CoAP, AMQP, MQTT, SIP, and WM-Bus – with respect to their ability to be used as MTC containers. One of the key MTC enablers is the WM-Bus protocol, which is based on an open standard for automatic meter readout. The design of the protocol implies a communicating 4 See Miners tap into rich seam of “Internet of Things”, Financial Times, 2016: https://www.ft.com/content/854fb212-084b-11e4-9380-00144feab7de 5 See Top 5 industrial IoT companies, RCR Wireless News, 2016: http:// www.rcrwireless.com/20160901/fundamentals/top-industrial-iot-tag31-tag99 6 See The first complete smart metering project in Austria – a model solution for whole Austria, Kamstrup, 2017: https://www.kamstrup.com/en-us/ case-stories/electricity-casestories/case-telekom-austria-system-at

ISBN 978-3-8007-4426-8

SUPPORT OF

SIP

Infrastructure Protocols

Service Discovery Routing Protocols Network Layer Link Layer Physical Layer

CoAP

Protocol

DDS

TABLE I S TANDARDIZATION ACTIVITIES IN

XMPP

Even though the companies mostly leverage the IIoT as a tool for operational efficiency, the prospects of this paradigm are much wider. Companies crafting equipment and other tools can employ IIoT to introduce new products and services, therefore generating entirely new revenue sources. As an example, we may consider a mining company, where the ability to analyze the ore quickly can make a tremendous impact in mining techniques and prevent from potential breakdowns4 . Similar solutions are under development across most of the industry fields. The leading companies from the telecommunication side involved into supporting this progress are Cisco, AT&T, General Electric, Bosch, and Intel5 . Since the main IIoT trends are already well known, this paper is mainly focused on Wireless M-Bus (WM-Bus) protocol as an enabler for the IIoT technology. The protocol is standardized (EN 13757-4) and operates on unlicensed 169, 433, and 868 MHz frequencies. It was specifically developed for communication between utility meters, data loggers, concentrators, and smart meter gateways (MachineType Communication Gateways; MTCG) [10]. Currently, this technology is widely deployed by many energy providers in Europe, including Telekom Austria Group (TAG)6 . In this paper, we expand our vision of the IIoT for embedded devices basing on our previously developed industrial projects [11]. In particular, we consider the situation, when low-cost IQRF radio modules can be configured in the role of Wireless M-Bus receivers. Inspired by that, we analyze and implement a real-world scenario, where the IQRF TR72DA-WMB module becomes a part of the MTCG device and receives the MTC data sent via the WM-Bus communication protocol from various types of smart metering devices (electricity meters, water meters, temperature and humidity sensors, etc.). We thus focus on secure MTC data transmission within our trial implementation.

41


European Wireless 2017 TABLE II WM-B US PROTOCOL TRANSFER MODES Frequency

Cod. Scheme

S

Stationary

Transfer type

868 MHz

32768 kbps

T

Frequent transmit

868 MHz

R N C

Frequent receive Narrowband Compact Frequent transmit and receive

868 MHz 169 MHz 868 MHz

Manchester Manchester a 3 from 6 Manchester NRZ Manchester

433 MHz

NRZ

–

F

Speed

100 kbps 4.8 kbps 50 kbps Fig. 2. Utilized IQRF TR-72DA-WMB module.

MCU

III. W IRELESS M-B US FRAME STRUCTURE

Wireless M-BUS

After the protocol operation modes and the topology have been introduced, we focus on the data frame structure to make the reader more familiar with the WM-Bus operational details. This section provides a description of the WM-Bus communication phases (handshakes). In the first step, an overthe-top application at the application layer of WM-Bus sends its data to the RF module as a packet – as demonstrated below: 1 Byte CI

– 5.3V

1 Byte C

2 Bytes ManID

6 Bytes Address

n Bytes AppLayer

1 Byte CI

1 Byte CI

n Bytes AppLayer

UART

TX

TR-72D-WMB

Wireless M-BUS

TR-72D-WMB

RX TX

Converter UART

MTCG

RS-232, RS-485, USB CDC

The said module supports WM-Bus S1, S2, T 1, and T 2 operating modes. The power voltage is in the range from 3.1 to 5.3 V with the maximal current of 1 µA in the sleep mode and 8-22 mA in the transmit mode. This value is based on the output power setting, which caps at 12.5 W. The module has support for 169, 433, and 868 MHz frequency bands, whereas the chip supports operation in one of the following modes:

1 Byte RSSI

•

•

1 Byte RSSI •

The AppLayer field is defined by the M-Bus application layer, and is used as a transition mechanism for the communication from link layer to higher layers. It uses the OMS 3.0.1 specification [13] derived from the EM 13757-4 standard for wireless communication [14]. In this work, we focus primarily on one of the WM-Bus equipped devices – IQRF radio modules. For our implementation, we used the IQRF TR-72D-WMB module (see Fig. 2) [15]. This module is from the programmable IQRF technology line produced by MICRORISC that allows to implement the Wireless M-Bus or a similar protocol on the fly. It is equipped with SPI and UART interfaces for communication with the master devices. Its block diagram is depicted in Fig. 3.

ISBN 978-3-8007-4426-8

3V

Fig. 3. Block diagram of TR-72DA-WMB module.

This packet is further encrypted (with AES-128 by default) and transmitted. If the connection is implemented as tunneling (P2P connection) between two Wireless M-Bus modules, the address field and the affiliated info is optional – thus allowing for simpler packet structure by sending only the RSSI: 1 Byte Length

RX

UART

n Bytes AppLayer

LDO voltage regulator

3V

In the next step, the radio module adds the following fields: (i) Control field; (ii) Manufacturer identification; (iii) Unique address based on parameters saved in the memory of the modules; and (iv) Optional information about received signal strength (RSSI). Therefore, the packet now has the following headers: 1 Byte Length

Wireless M-BUS

EEPROM 32 KB

MTCD

1 Byte Length

RF

Meter: The module can be connected via UART to the micro-controller, which serves as a data handler i.e., it could be utilized to build the proprietary measurement devices based on WM-Bus protocol. Multi-Utility Controller: The module serves as communication device for the meter data readout. Current firmware only supports bidirectional communication with meters in S and T modes, and is still under development. Sniffer: The module captures all the available communication in the selected transmission mode. Owing to the implementation of the Wireless M-Bus protocol, it can also capture and decrypt the encrypted communication.

In our scenario, the module communicates with the master micro-controller over UART with the predefined parameters: (i) 19200 Bd, (ii) 8 bits, (iii) none parity, and (iv) 1 stop bit. To control and communicate with the module, a specific predefined set of commands could be utilized. The configuration command starts with > and the response begins with [CC][RW ][DAT A][CR] < [DAT A][CR] Here, CC stands for the one-byte code of the command itself, RW is the one-byte index defining read (:) or write (?) data, and CR is the finishing character DATA: (i) in case of the configuration, the information to be stored, or (ii) in case of the reply, payload data or return codes – OK for successful finish, ERR1 for syntax error, and ERR2 for invalid input value. Below we outline readout and alteration of the AES key to illustrate the aforementioned sequence. Query and answer for the AES key are:

Fig. 5. Details on fitted IQRF module.

> 03?[CR] < 010203040506070809a0b0c0d0e0f [CR] //and for the alteration of the key > 03 : 112233445566778899aabbccddeef f [CR] < OK[CR]

•

The final received data frame structure for TR-72DA-WMB module is: 1 Byte Length

1 Byte Status

12 - n Byte ...

1 Byte CRC

1 Byte RSSI

1 Byte CR

1 Byte 0A

After the preliminary testing, we may now proceed with the characteristic scenario description. •

IV. P ROTOTYPING AN I NDUSTRIAL I OT S CENARIO We have selected Raspberry Pi3 with Input/Output shield for our implementation. The connection between the Raspberry Pi and the shield is via the 26 pin board. The UART bus is escorted to the SIM slot on the shield, which is prepared for the connection. It is equipped with the IQRF module as it is shown in Fig. 4 and Fig. 5.

mounted case. It supports S and T transmission modes including the adjustable settings for AES128 encryption in CBC mode. Transmission interval can be set to 1, 5, 10, or 15 minutes. Bonega module is the wireless sensor equipped with Wireless M-Bus protocol stack. It is a standalone device designed to fit on Bonega water meters. The electronic part of the modules serves for both cold and hot water readout. Therefore, it transmits two separate encrypted packets with different 6th address byte, for both cold and hot water measurements. It operates only in T 1 mode with AES 128 in CBC mode. The transmission interval is ranging from 20 to 24 seconds inside subtractive seasons and 4 minutes outside. ZPA ZE310 is the three-phase double-tariff electricity meter for active energy measurements designed for direct and indirect connections. This specific model is operating only in mode T 2, by sending data from both tariffs in one-minute intervals.

All the aforementioned devices support a data format according to the OMS 3.0.1 [13] specification, which derives from the EN 13757-4 [14] normative for wireless communication.

Fig. 4. Details on Raspberry Pi and shield connection. (a) Weptech OMST-868A

Several devices supporting the Wireless M-Bus protocol were utilized in our prototyping phase: (i) Weptech OMST868A [16] room temperature and humidity sensor; (ii) ZPA ZE310 [17] electricity meter; (iii) Kamstrup Multical 402 [18] ultrasound heat meter, and (iv) Bonega [19] water meter module. • Weptech OMST-868A (see Fig. 6(a)) is the temperature and humidity sensor with Wireless M-Bus support. It is designed for indoor usage and therefore is shipped in wall

ISBN 978-3-8007-4426-8

(b) Bonega water meter

(c) ZPA ZE310

Fig. 6. WM-Bus equipped devices of interest.

43



On the other hand, the relevant AES key could be downloaded from the vendor database and used to decrypt the data. Validity of the decrypted data is verified by bytes on the positions 34 to 37 of the packet, which must contain 2F2F value if the decryption was successful. Finally, we have decrypted the captured packet:

A. Implemented SW framework This subsection provides an overview of our trials with the devices, including a variety of tests and sample outputs. 1) Unencrypted Communication: We captured one Weptech sensor telegram with the communication module in Sniffer mode: 32002E44B05C10000000021B7A62080000 2F 2F 0A6699010AF B1A930202F D971D0100 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 879e0D0A

32002E44B05C10000000021B7AC4082005 2F 2F 0A6699010AF B1A930202F D971D0100 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 879e0D0A

The packet was analyzed and the valuable data was retrieved based on the data sheet [16]. Selected parts of the analyzed packet are illustrated in Table III.

Clearly, this packet is mostly equivalent to the initial one, except for the access number and CRC highlighted in red. Based on the Weptech sensor specification [16], it is shown that for acquiring the measurement data there is a need to parse the bytes in the following positions: (i) 8-23 for the information about the sensor itself; (ii) 24-25 for the packet order number; (iii) 34-37 for the AES control bytes; (iii) 4245 for the measured temperature value; (iv) 52-55 for the measured humidity value; (v) 64-67 for the sensor state check; and (vi) (96) for the signal level. The final step before we proceed with the actual scenario is to interpret the data based on the specification i.e., readout in the LSB format, transfer from HEX to DEC system, and definition of the decimal point.

TABLE III A NALYSYS OF CAPTURED UNENCODED PACKET Position 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 40 42 44 50 52 54 64 66 94 96

Telegram 2E 44 B0 5C 10 00 00 00 02 1B 7A 62 00 00 00 2F 2F 66 99 01 1A 93 02 01 00 87 9e

Field

Description

Explanation

L-Field C-Field

Length Telegram type

Length 46 Bytes Send-no-Reply

M-Field

ManufacturerID

WepTech

Serial number

SN is 00000010

Device version Device type Response type Access number Device status Encryption definition Control sequence First quantity Temperature value Second quantity Humidity value Sabotage control Chargeout control Control checksum Signal strength

Second version Room sensor M-Bus 89. access Meter is OK Encryption not used Successfully received Temp. 10ˆ(-1) o C Temperature is 19.9 C Rel. hum. 10ˆ(-1) % Humidity is 29.3 % Meter was opened Battery is OK Telegram CRC is 87 Signal is -51 dBm

A-Field

CI-Field AccNo Status Config. Word AES encryption 1. data block 2. data block 3. data block CRC RSSI

B. Constructed Scenario To satisfy the aforementioned requirements, we selected the structure of the application as follows. After the device initialization process, the application checks whether all the components required for the runtime are accessible. The entire system is dependent on the PyCrypto and Serial libraries, as well as the SQLite database system. It manages the availability of the selected serial port. If the latter is opened successfully, a wake up request is sent to the module. Following the wake-up character, the command for switching module to the T 1 mode “Sniffer” is transmitted. If any of the above operations fails, the program is terminated by keeping the logs. If the start-up of the program completes successfully, the listening cycle is executed. Every incoming packet is subjected to a series of tests that check whether the medium sensing is successful. The first check is related to the length of the packet, which should be an odd multiple. Furthermore, it undergoes the basic application analysis and link-layer parsing, where the length of the packet is compared with the checksum in the header. Next, the CRC checksum, Cl field, Status field, and ConfigurationWord field are verified. After the packet validation is successful, we store the decrypted packet in the database. If the data is encrypted, the program automatically decrypts it according to the procedure described in Section IV-A2. In the next step, the data is analyzed with respect to the manufacturer of the sensor. The resulting values are supported with the current time-stamp, saved in the database together with the sensor info, and reported to the GUI.

2) Encrypted Communication: After the AES encryption was enabled, an encrypted telegram was also captured: 32002E44B05C10000000021B7AC40820053 ED44A38A9C3C86F 58210F 9B979353C39D C1D5E0C873EB81994D28C099EF 1D55B0080 Even though the packet was encrypted, some valuable data was still retrieved: (i) positions 30-33 contain information about the used encryption; (ii) 8-25 contain the data related to the compilation of the initialization vector; and (iii) 3893 contain the encrypted data. Next, the data was decrypted according to the standard [14]. The currently installed AES key in the IQRF module may be obtained and utilized together with the compiled initialization vector to encrypt the received data.

ISBN 978-3-8007-4426-8

44


European Wireless 2017 Temperature and humidity captured by Weptech OSMF868-A meter 30 44

29 28

42 27 40

25

Temperature

24

38

Humidity

23 36

22

Humidity [RH]

Temperature [C]

26

21 34 20 19

32

18 17

where we obtained hands-on experience with many third-party frameworks. As mentioned before, our work was intended as a proof-of-concept hardware implementation that significantly reduces the cost of Wireless M-Bus based communication platform. In our future work, we are planning to expand the functionality of our platform by adding support for more smart-meter vendors, as well as to further work with smart and connected IIoT enablers. ACKNOWLEDGMENT The work of BUT was partially supported by the National Sustainability Program under grant LO1401, and infrastructure of the SIX Center was used. A. Ometov was supported by the Ministry of Education and Science of the Russian Federation (the Agreement number 02.a03.21.0008). R EFERENCES

0

100

200

300

400

500

600

700

800

900 1,000 1,100 1,200 1,300 1,400 1,500

30

[1] S. Jeschke, C. Brecher, H. Song, and D. B. Rawat, “Industrial Internet of Things,” Cham, Switzerland: Springer, 2017. [2] D. O’Halloran and E. Kvochko, “Industrial Internet of Things: Unleashing the Potential of Connected Products and Services,” in World Economic Forum, p. 40, 2015. [3] G. H. Popescu et al., “The economic value of the Industrial Internet of Things,” Journal of Self-Governance and Management Economics, vol. 3, no. 2, pp. 86–91, 2015. [4] D. Floyer, “Defining And Sizing The Industrial Internet - Wikibon,” 2017. [5] P. Friess, Internet of things: converging technologies for smart environments and integrated ecosystems. River Publishers, 2013. [6] S. Heng, “Industry 4.0: Huge potential for value creation waiting to be tapped,” 2014. [7] G. P. Sullivan, R. Pugh, A. P. Melendez, and W. D. Hunt, Operations & Maintenance Best Practices. 2004. [8] B. Marr, “IoT And Big Data At Caterpillar: How Predictive Maintenance Saves Millions Of Dollars,” 2017. [9] W. McDonald, Scott Rockley, The Industrail Internet of Things. 2014. [10] A. Orsino, G. Araniti, L. Militano, J. Alonso-Zarate, A. Molinaro, and A. Iera, “Energy efficient IoT data collection in smart cities exploiting D2D communications,” Sensors, vol. 16, no. 6, p. 836, 2016. [11] P. Masek, J. Hosek, K. Zeman, M. Stusek, D. Kovac, P. Cika, J. Masek, S. Andreev, and F. Kr¨opfl, “Implementation of true IoT vision: Survey on enabling protocols and hands-on experience,” International Journal of Distributed Sensor Networks, 2016. [12] A. Orsino, M. Condoluci, and G. Araniti, “Spectrum Sharing Approaches for Machine-Type Communications over LTE Heterogeneous Networks,” in Internet of Things. IoT Infrastructures: Second International Summit, IoT 360 ◦ , Revised Selected Papers, Part I, pp. 167–178, Springer, 2016. [13] OMS-Group, “The Open Metering System specification.” http://omsgroup.org/en/oms-group/about-oms-group/, 2016. [14] EUROPEAN COMMITTEE FOR STANDARDIZATION, “EN 13757-4. Communication systems for meters and remote reading of meters - Part 4: Wireless meter readout (Radio Meter reading for operation in the 868870 MHz SRD band).” http://oldfjarrvarme.unc.se/download/1309/fj, 2003. [15] IQRF - Technology for Wireless, “TR-72D-WMB series.” http://www.iqrf.org/products/transceivers/tr-72d-wmb, 2016. [16] WEPTECH elektronik GmbH, “Wireless M-Bus / OMS Humidity and temperature sensor WEP-OMSF-868A.” https://www.weptech.de/products/oms-humidity-and-temperaturesensor-wep-omsf-868a.html, 2016. [17] ZPA Smart Energy a.s., “Trifazovy elektromer ZE310.” https://www.zpa.cz/produkty-a-reseni/elektromery:c1/ze-310:p4.htm, 2016. [18] Kamstup CR, “Nejflexibilnejˇsi meric na trhu MULTICAL 403.” https://www.kamstrup.com/cs-cz/products-and-solutions/thermalenergy-meters/multical-403, 2016. [19] Vodomery BONEGA, “Ultra-antimagneticke bytove vodomery s bezdratovym prenosem dat.” http://www.bonega.cz/vodomery/index.htm, 2016.

Time [Minutes]

Fig. 7. Data visualization example.

The final step is the data visualization. Database export is executed automatically every midnight to deliver the measured data over the last 24 hours to the Google SpreadSheet. For each sensor on the selected day, the separate worksheet is created. The data is further processed by using Google Graphs to enable the interactive readout from a sensor for each day, as it is shown in Fig. 7, where the temperature and humidity information captured by Weptech OSMF868-A meter is displayed. V. L ESSONS L EARNED AND C ONCLUSIONS In this section, we conclude our work and focus on the aspects that we faced in the course of our development together with the main findings. During the development and implementation phases of our project, we solved a number of challenges: (i) Raspberry Pi 3 uses different access to the serial interface – hence, modifications on the boot level were needed; (ii) communication between wireless IQRF module and the processing unit via UART had to be redesigned for our target case; (iii) the sniffed packets required re-encryption with the AES key of the IQRF module and were decrypted again to access the data; (iv) the implementation of the data packets is not identical across the manufacturers and therefore for each device the sniffed data needed to be analyzed separately; (v) third party libraries had to be used for data visualization. In the course of our development, we collected useful information and practical experience on many commercial products from WepTech, ZPA, Kamstrup, Bonega, and Pikkerton. These provide us with insights into the implementation of commercially utilized solutions that allow to create a universal platform for meter readout. Currently, we have an opportunity to read the data in any encrypted packet from the aforementioned meters and our plan is to extend this possibility by broadening the spectrum of companies. Another very important and crucial result was in the implementation of the visualization tools,

ISBN 978-3-8007-4426-8

45
