a vision of internet of things in industry 4.0 with … · sending/receiving routing of messages...

http://www.iaeme.com/IJECET/index.asp 1 [email protected]

International Journal of Electronics and Communication Engineering and Technology

(IJECET)

Volume 9, Issue 1, January-February 2018, pp. 1–12, Article ID: IJECET_09_01_001

Available online at

http://www.iaeme.com/IJECET/issues.asp?JType=IJECET&VType=9&IType=1

ISSN Print: 0976-6464 and ISSN Online: 0976-6472

© IAEME Publication

A VISION OF INTERNET OF THINGS IN

INDUSTRY 4.0 WITH ESP8266

Carlos M. S. Rodrigues, Bruno S. L. Castro

UFPA - Telecommunications Engineering,

Department of Federal University of Pará, Belém, Brazil

ABSTRACT

This article presents a case study with the introduction of ESP8266 module,

observing the types and levels of bandwidth and communication challenges with

wireless network sensors and the necessary requirements in hostile environments in

the industry 4.0 era, switching between QoS levels. The module may suffer when

applied in industry 4.0, using a communication type machine-to-machine (M2M) to

establish connectivity IoT (Internet of Things). The chosen protocol for

sending/receiving routing of messages was the Message Queuing Telemetry Transport

(MQTT) to be extremely light weight, simple to implement, and running on an

architecture publish/subscribe ideal for this type of environments.

Key words: Industry 4.0, ESP8266, IoT, MQTT, M2M

Cite this Article: Carlos M. S. Rodrigues, Bruno S. L. Castro, A Vision of Internet of

Things in Industry 4.0 with ESP8266. International Journal of Electronics and

Communication Engineering and Technology, 9(1), 2018, pp. 1–12.

http://www.iaeme.com/IJECET/issues.asp?JType=IJECET&VType=9&IType=1

1. INTRODUCTION

With the advent of the Internet of things, appears slowly the Industry 4.0, that raises many

curiosity and doubts in the research community. More and more reviews and research

conducted by industry-related institutes observe that the penetration and the progress of the

Industry 4.0 concept is very slow [1].

It is a slow process, science boosts the industry and the industry boosts the global

economic standards, since the great industry revolution, for over 300 years, the industry

pushes the economic markets around the world, but right now after many years later, a new

revolution is happening, it is named by many as Industry 4.0.

On the other hand, the evolution of the industrial Internet of Things (IoT) [2] and Industry

4.0 [3]-[4] creates the possibility of connecting computer automated control systems for

remote monitoring and rapid response to events requiring real-time handling [5] creating large

opportunities of business for companies and organizations.

A Vision of Internet of Things in Industry 4.0 with ESP8266


It is necessary watching new forms of communication that suits to the companies needs

because a Machine-to-machine (M2M) communication plays a critical component of Industry

4.0 and, thus, resulting in Internet or Intranet of Things (IoT) [6-7].

There is a growing interest in using IoT Technologies in various industries [8].

Organizations massively invest to develop applications that interact with hardware, such

Cyber-Physical Systems (CPS) technologies and Cyber-Physical Production Systems (CPPS)

platforms to create smart factories.

However, quite a few IoT applications are being developed and/or deployed in various

industries including environmental monitoring, health-care service, inventory and production

management, food supply chain, transportation, workplace and home support, security, and

surveillance. Atzori et al. [9] and Miorandi et al. [10].

Another protocol that emerged after 10 years of existence is MQTT, it was created at the

end of 90‟s, developed by Andy Standford-Clark; MQTT is original from IBM, and since its

creation has been send to the Organization for the Advancement of Structured Information

Standards (OASIS) for standardization, where the current version of the standard protocol is

3.1. [11].

It is the type of lightweight M2M protocol, that works into the meaning of message

exchange between Publisher and Subscriber. Making an analogy relative to the traditional

architecture Client/Server, it is asynchronous, that is, it does not need to know where each

node is.

Publisher works as the client, usually represented by wireless sensor networks (WSN) that

transmits the data to a centralized location, Broker works as the Server that keeps the data

temporarily or permanently, and lastly there is a Subscriber that receives the reading of these

data through asking, working as the end client. That is the big differential of this protocol,

because the internet is not a reliable place, where inbound communications normally are

blocked by firewalls or gateway applications, as shown in Figure 1

Figure 1 MQTT Protocol traffic flow

This way any Subscriber that knows the topic path, since it is not private, can request to

the Broker the desired data, and starts to receive all messages published by sensor.

Examples of subscriptions:

AIO_USERNAME/feeds/temperature

AIO_USERNAME/feeds/+/temperature

AIO_USERNAME/feeds/#



In the first example, it is shown a basic subscription of a topic named temperature, in the

second there is a symbol wildcard (+) that allows accept any data on that level, in the third

example the (#) allows accept any data below of a determined level, thus to have access to

any data on the feeds topic, without to know the total topic path is extremely required use this

symbol at the end.

The used module at the proposed scenario is the ESP8266, a low cost, high performance

System on Chip Wi-Fi to serial module, part of Espressif System‟s „Smart Connectivity

Platform‟ that aims to provide mobile platform designers to innovate systems with embedded

Wi-Fi Capabilities at the lowest cost with the greatest functionality [12].

This module operates in 802.11 g/b/n modes. It is comprised of 32bit processor Tensilica

Xtensa LX106 running at 80 MHz, 512KB SPI Flash, 64KB SRAM, 96KB DRAM, 16 GPIO

Pins, 2.4 GHz Wi-Fi that supports WPA/WPA2 and one 10 bit ADC[13]. It can operate

within a temperature range of -40C to 125C, according to the manufacturer ESPRESSIF

Systems.

Other research does not address issues related to interference that may be caused by

electronic devices and things in the concept of Industry 4.0, but in this first scenario we will

address the behavior of the MQTT protocol, changing the quality of service.

The proposed model starts to simulate the environment of Figure 2 in laboratory

environment with the introduction of TCP (transmission control protocol) traffic within the

LAN, registering the values with IPERF [14] a tool for active measurements of the maximum

achievable bandwidth on IP networks.

This tool supports various parameters related to timing, buffers and protocols (TCP, UDP,

SCTP with IPv4 and IPv6). For each test it reports the bandwidth, loss, and other

parameters. for further analysis. [15].

Figure 2 Proposed scenario for environment simulation IoT

For the setup proposed to measure the publication of the topics with QoS expected were

used:

Client iperf: Windows 7, with Intel processor i686 @ 3,2Ghz and 6GB of RAM.



Server iperf: Linux version 3.2.82-1, with Intel processor i686 @ 2,8Ghz and 3GB of RAM.

Publisher: ESP8266 32-bit Xtensa @ 80MHz and 64KB of RAM.

Subscriber: Windows 7, with Intel processor i686 @ 3,8Ghz and 4GB of RAM.

Router AP: Motorola SVG1202, working in 802.11n, frequency 2412 MHz and channel 1.

MQTT Broker: Adafruit website. [16]

The feeds in the MQTT broker can be seen in the Figure 3.

Figure 3 Dashboard in Adafruit website

This paper is organized as follows: Section II shows, a study about the sensor and the

MQTT protocol communication for the Industry 4.0 era. In section III an analysis is made for

QOS types in relation to the availability of the bandwidth. Section IV, provides the

conclusion.

2. SENSOR AND MQTT PROTOCOL

The module used in the proposed scenario is the board, official for development Node MCU

v3.0 with the chip ESP8266-12 built-in, as it is shown in Figure 4.

Figure 4 Node MCU firmware with a ESP8266-12 version 3.0

Nodev MCU is a elua based firmware for the ESP8266 WiFi SOC from Espressif. The

firmware is based on the Espressif NON-OS SDK 1.5.4.1 and uses a file system based on

spiffs. The code repository consists of 98.1% C - code that glues the thin Lua veneer to the

SDK.

The Node MCU firmware is a companion project to the popular Node MCUdev kits,

ready-made open source development boards with ESP8266-12E chips [17].

ESP8266EX integrates Tensilica L106 32-bit micro controller (MCU) which features

extra low power consumption and 16-bit RSIC, reaching a maximum clock speed of 160

MHz. With the Real-Time Operation System (RTOS) enabled and Wi-Fi stack functional,



about 80% of the processing power is still available for user application programming and

development [18].

The pinout scheme follows the presented in the Figure 5.

Figure 5 Pinout ESP8266 NodeMCU Dev-Kit [19]

For the purpose of our analysis in TCP/IP communication it was chosen the MQTT

protocol because it is extremely light, and it is ideal to environment with limited bandwidth

network and high latency probability in their transmissions.

Another reason is that the protocol is open, simple, and designed so as to be easy to

implement. These characteristics make it ideal for use in many situations, including

constrained environments such as for communication in Machine to Machine (M2M) and

Internet of Things (IoT) contexts where a small code footprint is required and/or network

bandwidth is at a premium [20].

Each MQTT Control Packet contains a fixed header [21] of 2 bytes, Figure 6 illustrates

the standard fixed header format.

Figure 6 Fixed header format [21]

On the position 1 (byte1) from the header bits [7-4] represents the type of control that the

MQTT establishes in the sent and received packets, the function defined for each one can be

seen on the table 1.



Table 1 Message Type

Name Value Direction flow Description

RESERVED 0 Forbidden Reserved

CONNECT 1 Client to Server Client request to connect

to server

CONNACK 2 Server to client Connect acknowledgment

PUBLISH 3 Client to Server Publish message

PUBACK 4

Client to Server

or

Server to Client

Publish Acknowledgment

PUBREC 5

Client to Server or

Server to Client

Publish received

PUBREL 6

Client to Server or

Server to Client

Publish release

PUBCOMP 7

Client to Server or

Server to Client

Publish complete

SUBSCRIBE 8 Client to Server Client subscribe request

SUBACK 9 Server to Client Subscribe

acknowledgment

UNSUBSCRIBE 10 Clien to Server Unsubscribe request

MQTT protocol delivers messages according to the level of established Quality of Service

(QoS), there are 3 levels as follows describe:

QoS level 0 – At most once delivery

QoS level 1 – At least once delivery

Qos level 2 – Exactly once delivery

In the level 0, according Figure 7, the data are delivered following the Best Effort

perspective, the protocol tries to deliver a message, but as it does not have received

confirmation this message may possibly be lost, and there is no guarantee that the receiver

will receive it. Following uploads with the same contents of the message are not made.

Figure 7 QoS level 0 protocol flow

In the level 1 according figure 8, already exists a knowledge (PUBACK) from the broker

to the Publisher, ensuring, this way, the client knows that the message was successfully

delivered to the subscriber.




When there is a fail during the message communication, by the link of node or the

Publisher does not receive the confirmation during a specific Time-to-Live (TTL) the

Publisher back to send the message using the header mechanism on position 1 (byte 1) bit [3]

with the set flag DUP, it is also important to refer that in the case of QoS level 1 and 2 exist a

specific Message ID to each sent message that works as an identifier in the Broker.

On the level 2, according Figure 9, all the process is a few more complex to guarantee that

the duplicated messages will not be delivered to the Broker.

This level of service qualities applied in systems where the duplicated sends are not

tolerated or possible to happen, as banker systems or space navigation.


In a network where there are several communication failures, MQTT only provides

recovery with QoS 1 or 2. If the client device fails, it is typically a catastrophic failure, rather

than a transient one [21].

The confirmation answer from the broker to the publisher is made by the message

(PUBREC) it guarantees to the client that the message was successfully stored, the broker

does not send immediately to the subscribers, it sends only when it receives the message

(PUBREL) from the client, after that the broker sends a (PUBCOMP) to the client, than

discards the original message because it knows that the message was successfully delivered

exactly once to the subscribers of the topic delivering.



At the level of impact on the performance of the sending of messages the choice of QoS

has special importance in the total transmission times, the following equations will be

considered:

)

+

Where,

→ Number of messages.

→ Time of publish message.

→ Time of publish acknowledgment.

→ Time of assured publish received.

→ Time of assured publish release.

→ Time of assured publish complete.

For the transmission of 100 topics, taking into consideration that the takes approximately

0.5 sec. and the messages , , take approximately 0.4 sec. on a network without bottlenecks,

we can observe the following message delivery times:

100 * 0,5 = 50 seconds

100 * (0,5 + 0,4) = 90 seconds

100 * (0,5 + 1,2) = 170 seconds

We can observe that the choice of QoS may have certain limitations in networks with time

restrictions, another limitation verified during the review process is that the MQTT, besides

being a protocol that predicts QoS, it does not present no queue mechanisms, or periodization

in the message urgency.

The protocol only speaks with topics [22] does not exist no queue proposals to the

management of the topics send to the broker, neither its internal treatment as its delivery to

the subscribers, that are clients of this same topic.

3. MEASURING BANDWIDTH WITH QOS

For all the tests, we used wavemon on the linux, near to module ESP8266 to register the

values of link quality, signal level, noise level and Signal-to-noise (SNR) and those values can

be seen in Figure 10.



Figure 10 Capture quality condition for WiFi transmissions

With the IPERF tool utilization, were sended TCP packets types to occupy the bandwidth

during 100 sec. with the following command:

iperf -c 192.168.0.2 -P 1 -i 1 -p 5001 -f m -t 100

From the other end of the local network (LAN) another computer listen to the packets on

port 5001 through the following command:

iperf -s -t -P 0 -i 1 -p 5001 -f m

Table 2 The bandwidth server analysis

ID Interval Transfer Bandwidth

4 0.0-30.0 sec 158

MBytes

13.2Mbits/sec

With this test, it can be observed from Figure 11, the values of channel occupation vary

between the values of 11,0 to 13,8 Mbits/sec, with a slight drop of a packet in the instant of

time 13 sec., marking the value of 1,3Mbits/sec.

Being the average bandwidth for the channel used equal to 13,2 Mbits/sec.

Figure 11 Bandwidth used on server



After the band be filled, tests were performed for topics publications with the protocol

MQTT, the ping, rssi, temperature and humidity, in order to verify its behavior in wireless

sensor congestion network.

As the study is based on QoS 0 and QoS 1 utilization, the variations and losses of

packages are registered by the Internet Control Message Protocol (ICMP).

As shown in Figure 12, that the packet lost variation varies from 202 to 237,6 ms during

the periods of time of 21:01:40 – 21:04:45 with the publisher sending the data to the Broker

on cloud by the utilization of QoS 0.

Figure 12. QoS level to protocol flow

After this period, the network is flood by TCP SYN packets, that make a bottleneck on the

communication line, causing a channel failure. It´s possible to observe that between the period

of 21:04:45 to 21:08:10 there was an effective failure on reception by the subscriber from the

topic ping, and therefore in all the others topics, because the local network was loaded of TPC

SYN packets.

From the instant 21:08:10 to 21:09:35, the module ESP 8266 was configured to change

the service quality to QoS 1, and this way you can verify that the packets start to be delivered

to the subscriber again, however in the message headers of the publisher a flag DUP was set

up to 1, instead of DUP 0, that is the protocol working standard.

This fact is verified because the MQTT Broker tries to send many times the PUBACK to

the publisher, but it finds congestion on the network and the delivery fails, then, the client sets

up the DUP to 1, and tries publish the message to the MQTT broker several times until its

receipt acknowledgment.

From 21:05:50 to 21:08:10 all the messages have been lost, because QoS 0 has no

mechanism to know if the messages were delivered successfully or not, already in QoS 1, this

guarantee is assured, the fact of the messages starting to be delivered again was not only

because the QoS was changed, but because the channel congestion decreased, however, even

if network congestion lasts longer with high values of traffic, all messages would be delivered

later in a certain time.

This is possible because with QoS 1 the MQTT broker stores the messages in the cloud

and after that publish the messages to the subscriber and in the end deletes them.



4. CONCLUSIONS

In this paper, we discussed some aspects referents to the service quality, and the transmission

reliability. Industrial communication requires very high reliability especially for control, and

safety applications [23].

Thus, it was possible to conclude that through the MQTT protocol utilization, even if

there is a band occupation filling almost all the channel, the verified bottlenecks cannot

prevent the subscriber of receive the topics, providing a resilience to a reliable package

delivery with QoS .

About the less reliable transmissions, the QoS 0 configuration can be used, but there is no

package delivery guarantee, what does not fit the point of view to the industry 4.0, which as

one of its first objectives, to ensure a reliable environment.

For further works, it is intended to continue to use the quality of service in MQTT,

introducing and analyzing interferences on transmissions, in order to study their behavior in

hostile environments, subject to failure on data transmission.

REFERENCE

[1] R. Frank, L. Caius, D. Anca, “Service Provision in the Framework of Industry 4.0”.

[2] R. Want, B. Schilit, and S. Jenson, “Enabling the internet of things,” IEEE Computer, vol.

48, no. 1, pp. 28–35, Jan. 2015.

[3] J. Lee, “Industry 4.0 in big data environment,” Harting Tech News, vol. 26, 2013.

[4] Intel Corp., “The Internet of Things (IoT) starts with Intel inside,” 2015. [Online].

Available: http://www.intel.com/content/www/us/en/internet-of-things/overview.html.

[5] Michael W. Condryand CatherineBlackadar Nelson “Using Smart Edge IoT Devices for

Safer, Rapid Response With Industry IoT Control Operations”.

[6] J. Höller, V. Tsiatsis, C. Mulligan, S. Karnouskos, S. Avesand, D. Boyle, ”From

Machine-to-Machine to the Internet of Things: Introduction to a New Age of

Intelligence”, Elsevier, 2014, ISBN 978- 0-12-407684-6.

[7] Jazdi N, "Cyber physical systems in the context of Industry 4.0", IEEE International

Conference on Automation, Quality and Testing, Robotics, 2014.

[8] Y. Li, M. Hou, H. Liu, and Y. Liu, “Towards a theoretical framework of strategic

decision, supporting capability and information sharing under the contexto of internet of

things,” Inf. Technol. Manage., vol. 13, no. 4, pp. 205-2016, 2012.

[9] L. Atzori, A. Iera, and G. Morabito, “The internet of things: A survey,” Comput. Netw.,

vol. 54, no. 15, pp. 2787–2805, 2010.

[10] D. Miorandi, S. Sicari, F. De Pellegrini, and I. Chlamtac, “Internet of things:Vision,

applications and research challenges,” Ad Hoc Netw., vol. 10, no. 7,pp. 1497–1516, 2012.

[11] IBM, “Desenvolva um sensor de Temperatura pronto para a nuvem com o Arduino Uno e

o IBM IoT Foundation, Parte 2.”. [Online]. Available:

http://www.ibm.com/developerworks/br/cloud/library/cl-bluemix-arduino-iot2/. Last

access in 19/11/16.

[12] Manan Mehta, “ESP 8266: A Breakthrough In Wireless Sensor Networks And Internet Of

Things”, in International Journal of Electronics and Communication Engineering &

Technology (IJECET) Volume 6, Issue 8, Aug 2015.



[13] Wi-Fi Module, “ESP8266EX Datasheet”. [Online]. Available: http://www.adafruit.com.

Last access in 09/11/16.

[14] A Tirumala, F Qin, J Dugan, J Ferguson, K Gibbs, “Iperf-The TCP/UDP bandwidth

measurement tool”, http://dast.nlanr.net/Projects/Iperf/, 2005.

[15] IPERF “The ultimate speed test tool for TCP, UDP and SCTP”. [Online]. Available:

https://iperf.fr/. Last access in 12/12/16.

[16] Adafruit, “Dasboard”. [Online]. Available: https://io.adafruit.com/. Last access in

15/12/16.

[17] NodeMCU, “Lua based interactive firmware for mcu like esp8266”. [Online]. Available:

https://github.com/nodemcu/nodemcu-firmware. Last access: 10/12/16

[18] Espressif, “Low-power, highly-integrated Wi-Fi solution”. [Online]. Available:

http://espressif.com/products/hardware/esp8266ex/overview/. Last access: 21/11/16.

[19] ESP8266 NodeMCU, “Comparison of ESP8266 NodeMCU development boards”.

[Online]. Available: http://frightanic.com/iot/comparison-of-esp8266-nodemcu-

development-boards/. Last access: 13/12/16.

[20] S. Shubhangi, N.Pooja, S. Shubhangi, S. Vrushali, J. Yogesh, “MQTT- Messge Queuing

Telemetry Transport protocol”.

[21] MQTT, “MQTT v3.1 Protocol Specification”. [Online]. Available:

http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt- v3r1.html. Last access:

17/10/16.

[22] MQTT OASIS Standard, “MQTT version 3.1.1”. [Online]. Available: http://docs.oasis-

open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html. Last Access: 08/12/16

[23] A. Varghese and D. Tandur, “Wireless requirements and challenges in industry 4.0,” in

Contemporary Computing and Informatics (IC3I), 2014 International Conference on.

IEEE, 2014, pp. 634–638.

a vision of internet of things in industry 4.0 with … · sending/receiving routing of messages...

Documents