IRJET Development of A Multipurpose IoT

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056
Volume: 06 Issue: 08 | Aug 2019 www.irjet.net p-ISSN: 2395-0072
Development of a Multipurpose IoT based Energy & Remote Asset

Monitoring and Control System
Rex Smith1, Amitkumar Patel2
1Lead Engineer, Corporate Digitalization Group, D&IT, TATA Power Company Ltd., Mumbai, Maharashtra, India
2Lead Engineer, Business Collaboration, TATA Power Company Ltd., Mumbai, Maharashtra, India
---------------------------------------------------------------------***----------------------------------------------------------------------
Abstract - In the past decade, the rise in fuel costs combined with the demand for cheap power has forced power utilities
around the world to increase their tariffs. To offset this, power utilities are not only reducing their operating costs through
industrial automation but also offering value added services to their end customers. The Indian power market is no exception
to this change, however due to the availability of cheap labour in India, the adoption of new and innovative technologies has
been relatively slower. Fortunately, this trend is changing and utilities (especially private ones) are embracing new
technologies which would help them reduce cost as well as increase customer satisfaction. TATA Power, being a pioneer in
adopting new and emerging technologies, has invested in multiple such technologies; one of which is Internet of things (IoT).
In this paper, we address the overall development of two different projects based on the same technology; one is an IoT based
energy monitoring solution for residential & commercial customers, and the other is an IoT based remote asset monitoring &
control solution for Hydro Generation Plants.
Key Words: Internet of Things (IoT), Industrial Internet of Things (IIoT), ESP-32, SIM800l, Arduino, Open Source, ESP-IDF
1. INTRODUCTION
Internet of Things or IoT as it is commonly known as, is an intelligent network which connects all things to the
Internet for the purpose of exchanging information and communicating through the information sensing devices in
accordance with agreed protocols. It achieves the goal of intelligent identifying, locating, tracking, monitoring, and
managing things [1]. The term Internet of Things was first coined in 1999 by Kevin Ashton (while working for P&G) to
attract management attention towards RIFD, a new technology at the time. However, it took another 10 years for the
concept of IoT to gain some publicity [2].
1.1 Exodus from traditional M2M technologies towards Industry 4.0
It is estimated that by 2020 IoT will be a US$8.9 trillion market [2]. A big chunk of this would be from Industry 4.0
or Industrial Internet of Things. Morgan Stanley estimated in 2015 that by 2020, IIoT market will be worth US$110 billion.
These estimates are not only because of the technological advantages (remote troubleshooting, predictive data analysis,
scalability, etc.) that IIoT presents but also due to how easy it is to deploy. It was due to these reasons, we decided to base
our solution on this technology.
1.2 Use case 1: IoT based Energy Monitoring Solution 2
Although TATA Power already has a mature AMR (Automatic Meter Reading) infrastructure in place; there was
still a need for a cheaper and more compact energy monitoring solution. This would allow the end consumer to monitor
room/ sub-area level (in some cases even equipment level) energy consumption. From a commercial standpoint, TATA
Power intends to provide these devices as value added services to its consumers. Hence, these devices not only had to be
cheap, they needed to be reliable as well. Once installed at the consumer premises, the data collected by the devices would
enable the consumer to not only monitor their consumption on real time basis, but also get useful insights about their
consumption pattern (both present and forecasted) and equipment health. They would also receive tips to help them
reduce their power consumption.
1.3 Use case 2: IIoT based Remote Asset Monitoring & Control Solution
TATA Power has 3 hydro generation sites spread across nearly 500 sq. Km area in Maharashtra. Due to the sheer
size of the hydro generation sites, it is very expensive to lay PLC infrastructure at all remote nodes to monitor various
equipment and parameters. Hence, an IIoT device at these locations would prove to be a cheaper alternative to PLCs. They
would not only do away with the errors associated with manual reading and conveying of various parameters, but also
© 2019, IRJET | Impact Factor value: 7.211 | ISO 9001:2008 Certified Journal | Page 16
enable better operational decision making by provide data at real time basis. Over time they may also help in manpower
optimization by making these remote locations completely unmanned.
1.4 Objectives of the Project
a) Use case 1: Design and develop a working prototype of an IoT device in a compact 25mm DIN rail mount
packaging. The device should have the following features:
i. Communication over either Wi-Fi or GSM network

ii. Onboard data storage in case of communication failure
iii. Handle SSL certificate or use tokens for authentication
iv. Both electrically and programmatically fault tolerant
b) Use case 2: Design and develop a robust industrial grade IIoT device to capture various sensor data from remote
hydro operational locations. The device should have the following features:
i. Weatherproof enclosure
ii. Redundant power supply
iii. Communication over either Wi-Fi or GSM network
iv. Onboard data storage in case of communication failure
v. Handle SSL certificate or use tokens for authentication
vi. Both electrically and programmatically fault tolerant
2. METHODOLOGY
This section deals with the path and thought process followed in designing and setting up an End-to-End ecosystem for IoT
devices in Tata Power.
2.1 Project Plan Flow Chart
Fig -1: Project plan flow chart
2.2 Hardware & Firmware Version Methodology

While finalizing the milestones for this project, it was decided to approach the hardware and software development in
stages. This would enable the management to quantifiably measure the work done for each milestone. It would also ensure
an MVP (Minimum Viable Product) was available early in the project. The following H/W (Hardware)& F/W (Firmware)
versioning was finalized:
a) H/W v1.0 & F/W v0.9 to v2.1:
i. Different PCB designs for the Wi-Fi & GSM Devices with separate RS485 module
ii. The power supply was not integrated with the device
iii. The devices were only capable of reading the energy meter and sending the data to the MQTT broker
b) H/W v2.0 & F/W v2.2 to v3.5:

i. The power supply was integrated with the IoT device
ii. The devices now maintained the timestamps on the devices side as opposed to the server side on the previous
versions
iii. The devices were now tolerant toward connections drops
iv. Wi-Fi manager integrated with the Wi-Fi devices
c) H/W v3.0 & F/W v3.6 to v4.5:

i. Common PCB for both Wi-Fi and GSM devices with integrated RS485 module
ii. Onboard data storage in case of communication failure
iii. Two-way secure communication using X.509 certificates
d) H/W v4.0 & F/W v4.6 to v5.0:

i. Reduced the PCB footprint to fit a standard 25mm DIN rail mount IP58 case
ii. Added dual colour status LED
iii. Optimized the design files for mass manufacture
iv. Added RPC call activated FOTA on Wi-Fi devices
2.3 Description Hardware components
a) Main controller:
i. For hardware versions 1 & 2, ESP8266 was used for the Wi-Fi variant and ATMega328p was used for the GSM
variant
ii. For hardware versions 3 & 4, ESP32 was used as the main controller
b) GSM Modem:
i. SIM800L was used as the GSM Modem in all H/W versions
c) MODBUS to Serial (5V TTL) Converter:
i. For hardware versions 1 & 2, an off the self RS485 module was used for both variants
ii. For hardware versions 3 & 4, the RS485 circuit was integrated on the PCB itself
d) Power supply module:

i. For hardware versions 1 & 2, an off the self HLK-PM05 AC-DC converter was used for both the variants
ii. For hardware versions 3 & 4, the AC-DC converter circuit was integrated on the PCB itself
2.4 Selection of Firmware Development Environment
For H/W versions 1 & 2, Arduino IDE was selected as the firmware development platform as an MVP (Minimum
Viable Product) needed to be quickly developed. For H/W versions 3 & 4, ESP-IDF was chosen to be the development
environment; however, shortly after development H/W v3.0 started, it was decided to go back to Arduino. This decision
was taken as it would take a long time to develop the competency level of each member of the development team in ESP-
IDF. This in turn would cause issues in maintaining continuity in case any separation from the team/company. Moreover,
as the previous development was already done on Arduino, further development would be sped up too.
2.5 Selection of Energy Meter for Use Case 1
Eastron SDM120 Single-phase energy meter and Eastron SDM630 Three-phase energy meter were selected for this
project due to their form factor, cost and ability to communicate over MODBUS protocol.
2.6 Selection of IoT Platform and Server
Initially, Thinger.io was used to demonstrate data transfer from the meter to the main controller and unto the IoT
application (via MQTT protocol). However, Thinger was found to be very restrictive in terms of dashboards and
configurable parameters; hence, three other platforms were tested. Finally, Thingsboard was chosen (over Ubidots and
Grafana among other) as it provided the right balance between cost and features.
Next, it was decided to deploy Thingsboard on AWS (Amazon Web Services), as deployment options only included
AWS and Azure at the time and AWS was the lower cost option.
2.7 Development of IIoT based Remote Asset Monitoring & Control Solution (Use Case 2)
All develop for use case 2 (IIoT based Remote Asset Monitoring & control Solution) was done after completion of
H/W v4.0 and F/W v5.0 of use case 1. Hence, its hardware and firmware are mostly based on that of use case 1 (with the
exception of redundant power supply, onboard status display and IP68 casing).
3. ARCHITECHTURE
This section tries to highlight the architectures (only high level) used in various components in the IoT ecosystem.
3.1 Use case 1 final architecture (Data flow/ communication)
To ensure secure two-way transport encryption between the IoT devices and application servers without hardware
gateways in between, the X.509 certificate is stored on the SPIFF memory of ESP32 and the Public RSA Key is stored on the
server side within the IoT application.
Home Energy Management System

(Communication Architecture)
Communication between IoT IoT Application +Analytics Communication between
IoT Hardware + Firmware User Device
and Application Server Server Application Server and User
SSL Server Side Certificate
/X.509 Cert
Unique Access Token
/X.509 Cert
IoT Device collects data The IoT App server's built in The same server also houses The user logs into his
from the MODBUS enabled gateway recieves the data and the analytics engine which picks account hosted on the App
energy meter. It then accepts it only if the access up the data directly from the server via a secure TLS/SSL
encodes the data in JSON token matches. This data is then db and processes it. This data is connection and is able to
format and sends it along stored on POSTGRESQL or also visuallized in a different view both the live data and
with unique device token CASSANDRA. The App also dashboard for the end user. analytics data dashboards.
via MQTT to the IoT App visuallizes the live data on
Server. dashboards for the end users.
Fig -2: Use case 1 final architecture. This figure shows the flow of data from the end-point device to the server and finally
to the end user dashboards
3.2 Use case 2 final architecture (Data flow/ communication):

In use case 2, the same secure communication architecture is followed as above. Additionally, the main control unit
acts like a gateway for various peripheral units such as the I/O modules, sensor hubs, etc. This architecture saves costs as
only one gateway can handle 32 such MODBUS capable modules.
Fig -3: Use case 2 final architecture. This figure shows the flow of data from the end-point device to the server and finally
to the end user dashboards
3.3 Use Case 2 Application Example

This sub section describes an example application for the IIoT device to be deployed for monitoring and control of
remote assets. In this example, the IIoT device is controlling and monitoring 3 water pumps. The control is established via
a group of SPST relays which act as pilot relays for main replays controlling the input supply to the motors. In the initial
version, Bus PTs and clamp on CTs are used (via a sensor hub) to monitor the pumps; but in the later versions, SDM630 3
phase power analyzer was used as it is more accurate. All safety measures like overcurrent relays, thermal cut off relay,
etc. were wired in parallel with the IIoT device.
Fig -4: Use case 2 application example
3.4 Server side (IoT Application) Architecture

a) High Level Architecture:
The IoT application (ThingsBoard) contains set of core services that allow managing the following entities:
 Devices and their credentials
 Rule Chains and Rule Nodes
 Tenants and customers
 Widgets and Dashboard
 Alarms and Events
Rules can invoke a certain subset of this APIs. For example, a rule can create an alarm for certain device.
Fig -5: ThingsBoard High Level Architecture [3]
b) Actor Model:
Actor model enables high performance concurrent processing of messages from devices as long as server-side API calls.
ThingsBoard uses Akka as an actor system implementation with following actor hierarchies.
Fig -6: ThingsBoard Actor Model Architecture [3]
4. DEVICE HARDWARE AND FIRMWARE
This section describes the final hardware and firmware of both use case 1 and use case 2 devices.
4.1 Use Case 1 final hardware block diagram (v4.0)
The main controller and all other peripherals draw power from the onboard 5V 2.5A SMPS. The AC input of the SMPS comes
from the line out of the energy meter.
Fig -7: Use case 1 final hardware block diagram

*GSM module disconnected in Wi-Fi only devices
4.2 Use Case 1 Final Hardware Schematic (v4.0)
Fig -8: Use case 1 final hardware schematic
4.3 Use Case 2 final hardware block diagram

The main difference between the hardware in use case 2 and that of use case 1 are the integrated backup power supply
system and the onboard 3G/4G Wi-Fi dongle.
Fig -9: Use case 2 final hardware block diagram
4.4 Use Case 2 final hardware schematic
Fig -10: Use case 2 final hardware schematic
4.5 Final Firmware Flow Chart
The figure below is the flowchart of the final firmware version of the devices in both use case 1 and 2. It has 4 separate
routines namely: Data acquisition routine (MCU Reset/Reboot), GSM/Wi-Fi connection routine, Data save routine, and OTA
routine. The last two run on Core 0 and the rest on Core 1. Working of the program can be understood from the flowchart
below:
Fig -11: Final firmware flow chart
5. CONCLUSIONS/END PRODUCT
During the developmental period of this project, many learnings, in form of bug fixes on the firmware, PCB layout
issues, server setup/config setbacks, etc., were made. As these learns are now part of TATA Power’s knowledge matrix,
they cannot be covered under this publication. However, the images of the end user dashboards and IoT devices has been
added in this section as a testament of the quality and robustness of the final product of this endeavor.
5.1 End User Dashboards

The end user dashboards have been designed to be both insightful and easy to understand. The navigation to various
dashboard and dashboard states can be done easily using the standard ThingsBoard GUI. As described in section 3.4 b, the
same dashboard is assigned to various users; however, they can only see the data from the devices linked to them via the
role assignment module. This enables the system admin to only make a few standard dashboards and assignment to the
appropriate end users.
Fig -12: Live data Dashboard for Single Phase Meter IoT Device
Fig -13: Dashboard showing consumption data from a device
Fig -14: Dashboard showing tabulated data from a device
Fig -15: Main dashboard for Asset Monitoring Device
Fig -16: Dashboard showing live data from Asset Monitoring Device
Fig -17: Dashboard board showing all historical and live wind related data from an Asset Monitoring Device
5.2 End Point Devices
Fig -18: IoT device with a Single-Phase Meter
Fig -19: Hardware v4.0 IoT device (assembled)
Fig -20: Hardware v4.0 IoT device (rear view)
Fig -21: IoT device for Use Case 2
Fig -22: IoT device for Use Case 2 inside weatherproof IP68 enclosure
ACKNOWLEDGEMENT
The authors would like to express their gratitude towards Mr. Sydney Lobo (Chief - Business Collaboration) and Mr.
Manoj Kumar (Head – Program Management & Digital) without whose continuous support this project would not have
been possible to complete. Additionally, we would like to also thank Ms. Nushreen Ahmed (Lead Engineer – Corporate
Digitalization Group) for her attention to detail while proofreading this technical paper.
REFERENCES
[1] S. Chen, H. Xu, D. Liu, B. Hu and H. Wang, "A Vision of IoT: Applications, Challenges, and Opportunities With China
Perspective," in IEEE Internet of Things Journal, vol. 1, no. 4, pp. 349-359, Aug. 2014.
doi: 10.1109/JIOT.2014.2337336
[2] Margaret Rouse, IoT Agenda, IoT analytics guide: Understanding Internet of Things data, 2016
[3] ThingsBoard Architecture, ThingsBoard.io, 2019
BIOGRAPHIES
Rex Smith
Rex has been working on utility
scale digitalization projects like
UAV based asset monitoring, IoT
for energy monitoring, Switch
Yard Inspection Robot, etc. for the
past 4 years. Although he has
authored multiple technical
document, this is his first
publication in an international
journal.
Amitkumar Patel
Amitkumar has worked in the
power utility industry for the past
10 years. During this time, he has
pioneered multiple automation
projects at TATA Power. He also
holds an Indian patent for
“Robotic Painting for High Rise
Structures”.

IRJET Development of A Multipurpose IoT

Uploaded by

Copyright:

Available Formats

IRJET Development of A Multipurpose IoT

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IRJET Development of A Multipurpose IoT

Uploaded by

Copyright:

Available Formats

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 06 Issue: 08 | Aug 2019 www.irjet.net p-ISSN: 2395-0072

Development of a Multipurpose IoT based Energy & Remote Asset

1.2 Use case 1: IoT based Energy Monitoring Solution 2

1.4 Objectives of the Project

i. Communication over either Wi-Fi or GSM network

Fig -1: Project plan flow chart

2.2 Hardware & Firmware Version Methodology

b) H/W v2.0 & F/W v2.2 to v3.5:

c) H/W v3.0 & F/W v3.6 to v4.5:

d) H/W v4.0 & F/W v4.6 to v5.0:

2.3 Description Hardware components

d) Power supply module:

2.4 Selection of Firmware Development Environment

2.5 Selection of Energy Meter for Use Case 1

2.6 Selection of IoT Platform and Server

Home Energy Management System

SSL Server Side Certificate

Unique Access Token

3.2 Use case 2 final architecture (Data flow/ communication):

3.3 Use Case 2 Application Example

Fig -4: Use case 2 application example

3.4 Server side (IoT Application) Architecture

Fig -5: ThingsBoard High Level Architecture [3]

Fig -6: ThingsBoard Actor Model Architecture [3]

4. DEVICE HARDWARE AND FIRMWARE

4.1 Use Case 1 final hardware block diagram (v4.0)

Fig -7: Use case 1 final hardware block diagram

4.2 Use Case 1 Final Hardware Schematic (v4.0)

Fig -8: Use case 1 final hardware schematic

4.3 Use Case 2 final hardware block diagram

Fig -9: Use case 2 final hardware block diagram

4.4 Use Case 2 final hardware schematic

Fig -10: Use case 2 final hardware schematic

4.5 Final Firmware Flow Chart

Fig -11: Final firmware flow chart

5.1 End User Dashboards

Fig -13: Dashboard showing consumption data from a device

Fig -14: Dashboard showing tabulated data from a device

Fig -15: Main dashboard for Asset Monitoring Device

5.2 End Point Devices

Fig -18: IoT device with a Single-Phase Meter

Fig -19: Hardware v4.0 IoT device (assembled)

Fig -20: Hardware v4.0 IoT device (rear view)

Fig -21: IoT device for Use Case 2

You might also like