PERFORMANCE COMPARISON BETWEEN FIELDBUS SYSTEM AND LOCAL CLOUD TECHNOLOGY IN REAL-TIME CONTROL OF THE
INDUSTRIAL PROCESS
A Dissertation Presented to
The Engineering Institute of Technology
by
Ekwonyeaso Abel Uche
In Partial Fulfillment of the Requirements for the Degree
Master of Engineering in INDUSTRIAL AUTOMATION
JANUARY 2018
COPYRIGHT © 2018 BY EKWONYEASO ABEL UCHE
i
TABLE OF CONTENTS
Abstract ......................................................................................................................... ix
Chapter 1 Introduction ................................................................................................... 1
1.1 Background ....................................................................................................... 1
1.2 Problem Statement ............................................................................................ 3
1.3 Scope of Study .................................................................................................. 4
1.4 Thesis Hypothesis ............................................................................................. 5
1.5 Thesis Outline ................................................................................................... 5
Chapter 2 Literature Review and Related Work ............................................................ 7
2.1 Literature Review……………………………………………………………. 7
2.2 Fieldbus System ................................................................................................ 7
2.2.1 IEC 61158 Structure .................................................................................. 7
2.2.2 Types of Fieldbus ....................................................................................... 8
2.2.3 Features and Characteristics of Fieldbus System ....................................... 9
2.2.4 Advantage of Fieldbus System ................................................................ 13
2.2.5 Wired and Wireless Fieldbus ................................................................... 13
2.2.6 Wired Fieldbus ......................................................................................... 13
2.2.7 Profibus .................................................................................................... 14
2.2.8 Profibus and The OSI (Open System Interconnection) Layers ............... 15
2.2.9 Profibus Transmission Technology ......................................................... 17
2.2.10 Types of Profibus ..................................................................................... 18
2.2.11 Wireless Fieldbus System ........................................................................ 19
2.2.12 Types of Wireless Fieldbus ...................................................................... 20
2.2.13 Limitations of Wireless Fieldbus ............................................................. 22
ii
2.3 Cloud Technology ........................................................................................... 23
2.3.1 The Cloud Computing Service Delivery Model ...................................... 25
2.3.2 Cloud Computing Deployment Model..................................................... 26
2.3.3 Characteristics of Cloud System .............................................................. 28
2.3.4 Issues with Cloud System ........................................................................ 29
2.4 FOG Computing Technology ......................................................................... 30
2.4.1 Software Architecture of Fog Technology .............................................. 31
2.4.2 Fog Hierarchy of Operation ..................................................................... 32
2.4.3 Characteristics of Fog Computing ........................................................... 35
2.4.4 Fog Nodes ................................................................................................ 37
2.4.4.1 How Fog Nodes Operate ..................................................................... 38
2.4.5 Comparison between Cloud and Fog Computing System ....................... 38
2.4.6 Local Automation Cloud.......................................................................... 40
2.4.6.1 Local Automation Cloud Properties ................................................... 41
2.4.6.2 Mandatory Core Services and Systems ............................................... 43
2.5 Communication levels in an Industrial Plant .................................................. 44
2.6 Related Work .................................................................................................. 46
2.6.1 Cloud Computing for Industrial Automation Systems ............................ 47
2.6.2 Analysis of Profibus-DP Network Delay ................................................. 50
Chapter 3 Research Methodology ................................................................................ 51
3.1 Introduction ..................................................................................................... 51
3.2 Problem formulation or definition .................................................................. 52
3.3 System definition ............................................................................................ 53
3.4 Model Construction ........................................................................................ 53
3.4.1 Ethernet-based closed-loop control system model .................................. 54
3.4.2 Profibus DP Control system model.......................................................... 55
3.5 Input Data Collection and Analysis ................................................................ 55
iii
3.6 Model translation and Programming .............................................................. 56
3.7 Verification and Validation............................................................................. 56
3.8 Design of Experiment ..................................................................................... 56
3.9 Experimentation or Simulation and Analysis ................................................. 57
3.10 Documentation and implementation ............................................................... 57
Chapter 4 Experiment Setup and the Simulations ....................................................... 58
4.1 Introduction ..................................................................................................... 58
4.2 Model Systems Architecture Overview .......................................................... 58
4.2.1 Model System Architecture for Local Cloud ........................................... 58
4.2.2 Model System Architecture for Profibus DP ........................................... 60
4.3 Design of System ............................................................................................ 61
4.3.1 Model system components and their specifications ................................. 61
4.3.1.1 The Local Cloud System ..................................................................... 61
4.3.1.2 Arduino Mega 2560 ............................................................................ 62
4.3.1.3 Computers ........................................................................................... 65
4.3.1.4 Wide Area Network Emulator (WANem) .......................................... 65
4.3.2 The Profibus DP Simulation System ....................................................... 67
4.4 Step-by-step experiment procedure ................................................................ 72
4.4.1 Local Cloud System Experiment in LACN ............................................. 73
4.4.2 Method of Latency Measurement ............................................................ 73
4.4.3 Profibus-DP Model Control System Experiment .................................... 77
Chapter 5 Results and Analysis ................................................................................... 81
5.1 Introduction ..................................................................................................... 81
5.2 Result of Local Cloud Model System Experiment ......................................... 81
5.3 Local Cloud Experiment Result Summary ..................................................... 87
5.4 Profibus-DP Experiment Result Summary ..................................................... 88
iv
5.5 Analysis........................................................................................................... 88
5.5.1 T-Test Procedure ...................................................................................... 89
5.5.2 Result of Analysis .................................................................................... 93
5.5.3 Recommendations .................................................................................... 93
References ................................................................................................................... 94
v
LIST OF TABLES
Table 1 Background Information of Fieldbus System ................................................. 10
Table 2 Physical Characteristics of Fieldbuses ............................................................ 11
Table 3 Transport Mechanism of Fieldbus Standards ................................................. 12
Table 4 Performance of Fieldbus Standards ................................................................ 12
Table 5 Overview of Transmission Values .................................................................. 17
Table 6 Supported Fiber-Optic Cable Types ............................................................... 18
Table 7 Bands in Electromagnetic Spectrum ............................................................... 20
Table 8 Requirement Comparison Between Fog and Cloud Computing .................... 39
Table 9 Contrasting Cloud and Fog Computing .......................................................... 40
Table 11 Response Time as Converted from Digital Oscilloscope ............................. 80
Table 12 Result of the Local Cloud Model System Experiments ................................ 81
Table 13 Summary of the Local Cloud Model System................................................ 87
Table 14 Results from the Two Simulations................................................................ 89
vi
LIST OF FIGURES
Figure 1 Hierarchical Control System based on the Arrow-Head Framework .............. 2
Figure 2 Decomposition of the Automation Hierarchy by Cyber Physical System (CPS) With Distributed Services ........................................................................... 4
Figure 3 References Between OSI model and Profibus. .............................................. 15
Figure 4 PROFIBUS Protocol Communication Architecture. ..................................... 16
Figure 5 A Typical WirelessHART Network Architecture. ........................................ 21
Figure 6 Typical ISA100.11a Network Configuration. (From ISA100.11a-2011 Standard, Wireless systems for industrial automation: Process control and related applications, 2011.). ................................................................................. 22
Figure 7 Cloud Computing System ............................................................................. 24
Figure 8 Building Blocks of Cloud Computing System ............................................. 25
Figure 9 Components in Fog Software Architecture .................................................. 31
Figure 10 Different Uses of the Same Data ................................................................. 33
Figure 11 Analytics for Fog Computing. ..................................................................... 35
Figure 12 Arrowhead Local Automation Cloud .......................................................... 41
Figure 13 Arrowhead Core Systems and Their Use .................................................... 44
Figure 14 Different Communication Levels in a Plant ................................................ 45
Figure 15 ISA95 Architecture of Automation Systems ............................................... 46
Figure 16 Global Information Architecture With the Use of Cloud Computing ........ 48
Figure 17 Cloud-based Architecture for Industrial Automation .................................. 49
Figure 18 Flowchart Representing Typical Steps and Decisions for Conducting a Simulation Study .................................................................................................. 52
Figure 19 Block diagram of NCS ................................................................................ 54
Figure 20 Networked Control System ......................................................................... 58
Figure 21 Ethernet-Based Local Cloud Architecture Overview .................................. 59
Figure 22 Profibus-DP Simulation Model ................................................................... 61
Figure 23 Arduino Mega 2560 Control System Model ............................................... 62
vii
Figure 24 Arduino Mega 2560 Shield ......................................................................... 63
Figure 25 Arduino Mega 2560 RS-232 / RS-485 – Hardware .................................... 63
Figure 26 WANem Advanced Configuration Interface. .............................................. 66
Figure 27 Brad DRL-DPS-SRM Direct-Link Gateway/Profibus-DP Slave Module With 24VDC Power Supply Adapter ..................................................... 67
Figure 28 General Technical Specifications Brad DRL-DPS-SRM Direct-Link Gateway/Profibus-DP Slave Module ................................................................... 68
Figure 29 TCP’IP-TO-RS232/RS485 Converter ......................................................... 69
Figure 30 Tektronix Portable Oscilloscope (THS3000 Series) ................................... 70
Figure 31 Configuration Interface of the Profibus Master Simulator .......................... 72
Figure 32 Reflector Process known as the PING PONG (PINGING method) ............ 74
Figure 33 Advanced Configuration Interface of WANem .......................................... 75
Figure 34a Arduino Model Control System Web Interface for Real-Time Control When the ON command is Issued ........................................................................ 76
Figure 34b Arduino Model Control System Web Interface for Real-Time Control When the OFF Command is Issued ..................................................................... 77
Figure 35 Profibus Master Simulator Communication Settings Configuration Interface ............................................................................................................... 78
Figure 36 Selection of the GSD File and the Input/Output Parameters ....................... 79
Figure 37 Data Input Through Profibus Master Simulator .......................................... 80
Figure 38 Simulation 1 Experiment Ping Result. This is Without WAN/LAN Emulator (WANem)............................................................................................. 82
Figure 39 Result of Ping Response in Experiment 1, Simulation 2............................. 83
Figure 40 Result of Ping Response in Experiment 1, Simulation 3............................. 84
Figure 41 Result of Ping Response in Experiment 1, Simulation 4............................. 84
Figure 42 Result of Ping Response in Experiment 1, Simulation 5............................. 85
Figure 43 Result of Ping Response in Experiment 1, Simulation 6............................. 86
viii
ABSTRACT
The Cloud technology, which has emerged as a new computing concept or
technology has provided the guide for breaking the geocentric barrier in real-time
control of the industrial process. The Cloud technology through its inherent and
derived services has provided dynamic and flexible infrastructure [78], which could
provide an opportunity for real-time industrial process control for enterprise
organizations, whose operations, facilities and operation equipment are
geographically distributed and dispersed. The aim is to enhance and improve safe
operation, productivity, and customer service. In 2012, CISCO pioneered the FOG
computing technology for bringing the advantages and power of cloud computing
closer to where the data is being generated and acted upon [79]. However, the
requirements of the industrial automation systems differ significantly from the office
and enterprise world because industrial automation involves real-time control, which
is sensitive to delay, jitters and packet loss.
The essence of this thesis is to perform experimental comparisons between
latency and jitters used in a local system, and delay and jitters used in the Profibus-DP
network in real-time industrial process control. This study also presents an overview
of various technologies both in cloud and profibus systems. The aim is to provide an
objective outcome, which can be utilized to guide various interests in the investment
decision making. It provides a guide in the direction of research in the field of
industrial network and communication for real-time control, especially where there
are geographically dispersed and distributed facilities and service areas or locations.
A few related works are examined to identify gaps and opportunities for improvement
and advancement in the development of latency-proof systems in the field of real-time
ix
control, using capabilities of cloud technology to break geographical location barriers.
The experimental comparison is purely based on the simulation method using the
Wide Area Network Emulator (WANem) developed at the TATA research centre in
India, Arduino Mega 2560, Profibus-DP Master Simulator, and a few other off-the-
shelf protocol gateway and network devices. The results of the comparison
experiment is analysed using T-test.
x
CHAPTER 1. INTRODUCTION
1.1 Background
Real-time control is much desired in order to respond timely to variation in the
operation of an industrial process. The essence is to produce quality products and
services in a timely and safe manner to satisfy the needs of the customers. The aim of
real-time control is to ensure that the response time for command and control, data
acquisition, query and feedback between field devices, and the central control in an
industrial process is as small as possible to achieve a prompt response to customers’
needs, shorten product production time, prompt and accurate data provision and
enhance the overall quality of products and industrial process safety for the good of
all stakeholders, environment and industrial facility.
With the advent of cloud computing and the Internet of things (IoT)
technology, some experts have proposed their implementation in the industrial
process control, manufacturing, logistics and financial services. Much focus has been
given to data collection, data analysis and data utilization, which is great for
enhancement in productivity [1] and business services. It has also been a platform
opportunity to exploit virtualization and consolidate computing resources toward
enhancing productivity and optimizing cost [2].
However, the need to mitigate and overcome the network issues and
challenges encountered in using the cloud system in real-time control of industrial
processes has led to the concept of local cloud or fog technology [3], which comes
from the idea of migrating real-time industrial process control responsibility from the
1
“Global Cloud” to the “local Cloud” [4]. This is to achieve more service-based
industrial automation as depicted in Figure 1 below.
Figure 1 Hierarchical Control System Based on the Arrow-Head Framework [4].
This thesis project aims to study the effect of latency and jitters in real-time
control of industrial process when fieldbus and local cloud systems are used,
respectively, or separately, as part of the industrial network infrastructure. Latency is
generally known as a delay in data transmission, while jitters is a measure of variation
in delay as data or control command is transmitted from one hop to another along a
path of transmission up to the final destination. The study involves investigation on
how delays or latency and jitters affect the closed control loop and its response time
when local cloud technology is utilized on one occasion, and when Profibus DP,
which is part of fieldbus system, is used at another occasion to control the industrial
process. Performance comparison of these two different technologies in this study is
based on these parameters – latency, jitters and response times recorded in the
experiment when these technologies are used separately for the real-time control of
2
the same industrial process under their individual normal applicable implementation
conditions.
This thesis examines current industry trend and proposes a better mitigation
mechanism for real-time industrial process control issues, using a prototype, and a
number of experiments to evaluate the performance of the mitigation strategies. The
mitigation mechanism focuses mainly on delay and jitters that are larger than the
response period of closed-loop control system. The proposed mechanism is to
improve the closed control loop response time that is approximately close to the
closed-loop control performance in situation, where it executes locally, without any
servers (local cloud) and intelligent devises included in the loop.
1.2 Problem Statement
Fieldbus system used in the industrial network as a digital two-way
communication link [1] in the field operates at a low level in the structure of control
system hierarchy. The cloud computing system used in handling and storage of data
operates at higher levels with the end-user. There is a strong desire to harness the
benefits of cloud computing for the overall improvement of the industrial process
control. In a bid to provide a Web-Oriented Automation (WOA) based on cloud
technology, a WOA Architecture has been created [5] as shown in Figure 2. However,
little consideration is given to the fact that automation deals with real-time data
acquisition, monitoring and control of the industrial processes, and as such, is highly
affected by latency and jitters that are often experienced in the internet infrastructure.
The fieldbus system operates with low latency, required in real-time control of the
industrial process. The cloud system, which is connected with Wide Area Network
(WAN) exhibits higher latency, and is most often unpredictable.
3
Figure 2 Decomposition of the Automation Hierarchy by Cyber Physical System (CPS) With Distributed Services [6].
The challenge is to determine how to effectively integrate a cloud system into
a closed-loop control system and overcome the effect on latency when cloud
technology migrates from the higher level end-user in the industrial automation
hierarchy to the low field or control level, where it is called local cloud [7].
1.3 Scope of the Study
The objective of this study is to develop a platform for the analysis of and
comparison between the communication performances of the profibus system and that
of local cloud in terms of real-time control of the industrial process. The thesis
involves setting up of an experimental test platform for the evaluation of different
militating communication parameters encountered both in the fieldbus system and in
the local cloud. The main parameters of focus in this study are latency and jitters. This
study leads into making a proposal for the design and implementation of suitable
industrial network communication system, which would harness the benefits of both
4
the fieldbus system and the local cloud for the enhancement of real-time monitoring
and control of field equipment and the industrial processes.
The scope of this study is limited to the experimental analysis of the
performance of the profibus and local cloud. It also covers the demonstration of the
recommended proposal for implementation in industrial communication network.
This project proffers a cost-effective, efficient, and reliable solution to improve issues
of latency and jitters militating against real-time control in the industrial process.
1.4 Thesis Hypothesis
The hypothesis is that migrating cloud system from the high end-user level in
Automation Hierarchy to lower field-device level and implementing it as local cloud
would actually solve the problem of latency, and jitters has limits in real-time control.
This is geared toward minimizing the effects of latency and jitters associated with
cloud computing integration in real-time control and communication in the industrial
process. However, a comparison of effect latency and data loss in local cloud
networked-control system is compared with that of profibus networked-control
system would provide a guide on proper investment in industrial communication
infrastructure.
1.5 Thesis Outline
Section 1 gives an introduction about the topic of this thesis. The background
information on the technologies relating to the topic is presented together with some
related work done by some experts in the field in this study. Section 3 gives an
overview of the study methodology. The setting up of a platform for the
experimentation and simulation of the latency and jitters for the comparison of
5
performance between the profibus DP system and that of the local cloud system is
explained in Section 4. Section 5 provides a discussion on the results and
recommendations.
6
CHAPTER 2. LITERATURE REVIEW AND RELATED WORK
2.1 Literature Review
The literature review in this thesis concentrates on the presentation of the
industrial communication standards, technologies, architecture or platforms, and
infrastructure, which have been developed to enable real-time industrial process
control and automation. It also examines the previous work done to improve real-time
industrial communication and process control.
2.2 Fieldbus System
Fieldbus is a digital two-way multi-drop serial communication link between
intelligent field devices [8] and between sensors and transmitters. It is a local area
network (LAN) dedicated for industrial automation [9]. It is being used to replace 4 to
20 mA point-to-point centralized network. Fieldbus is used to establish distributed
control network and links for connecting isolated smart devices such as sensors,
transmitters and Intelligent Electronic Devices (IEDs) in the field [8]. The
standardization of Fieldbus was proposed to International Electrotechnical
Commission (IEC) in 1984 [9]. The standardization was recognized by
IEC/TC65/SC65C WG6 in 1985 [9]. The standard for fieldbus is now ISA SP 50 and
the IEC 61158 (Industrial communication networks – Fieldbus specifications), which
was reviewed last in 2008 [10].
7
2.2.1 IEC 61158 Structure [10]
IEC 61158 structure is divided into six parts [10]:
• “IEC 61158-1: Fieldbus for use in industrial control systems – Part 1:
Introductory guide” [10].
• “IEC 61158-2: Fieldbus for use in industrial control systems – Part 2: Layer
specification” [10].
• “IEC 61158-3: Fieldbus for use in industrial control systems – Part 3: layer
service definition” [10].
• “IEC 61158-4: Fieldbus for use in industrial control systems – Part 4: Data
link layer protocol specification” [10].
• “IEC 61158-5: Fieldbus for use in industrial control systems – Part 5:
Application layer service definition” [10]
• “IEC 61158-6: Fieldbus for use in industrial control systems – Part 6:
Application layer protocol specification” [10].
2.2.2 Types of Fieldbus [11]
Fieldbus was initially categorized in types as follows:
• Type 1 = Foundation Fieldbus H1
• Type 2 = ControlNet
• Type 3 = Profibus
• Type 4 = P-NET
• Type 5 = Foundation Fieldbus HSE (High-Speed Ethernet)
• Type 6 = SwiftNet (a protocol developed for Boeing, and has been since
withdrawn)
• Type 7 = WorldFIP
• Type 8 = INTERBUS-S
The IEC 61158 standardization was reviewed in 2008, in which case version
of the standard, the fieldbus types were reorganized into Communication Profile
Families (CPFs) as follows [11]:
8
• CPF 1: FOUNDATION Fieldbus
• CPF 2: CIP
• CPF 3: PROFIBUS
• CPF 4: P-NET
• CPF 5: WorldFIP
• CPF 6: INTERBUS
• CPF 7: SwiftNet (withdrawn)
• CPF 8: CC-Link
• CPF 9: HART
• CPF 10: Vnet/IP
• CPF 11: TCnet
• CPF 12: EtherCAT
• CPF 13: Ethernet Powerlink
• CPF 14: EPA
• CPF 15: MODBUS-RTPS
2.2.3 Features and Characteristics of the Fieldbus System
The features and characteristics of the fieldbus system depends on different
fieldbuses. The fundamental differences in data transfer methodology makes difficult
to make general comparison in terms of the features and characteristics [11].
However, the features and characteristics are presented in this thesis beginning with
the background of the fieldbus technologies show in Table 1.
9
Table 1 Background Information of Fieldbus System [12].
It is obvious from Table 1 that different fieldbuses are developed by different
organizations based on their needs. Table 2 shows a detailed physical characteristics
comparison compiled by ER-Soft S.A [12].
10
Table 2 Physical Characteristics of Fieldbuses [12].
In this report, there is also a need to present the transport mechanism and
performances of different fieldbus standards in order to guided the reason for the
choice of the fieldbus standard adopted for this study. Table 3 presents the transport
mechanism, while Table 4 shows fieldbus standards performances based on a study
conducted by ER Soft S.A [12].
11
Table 3 Transport Mechanism of Fieldbus Standards [12].
Table 4 Performance of Fieldbus Standards [12].
12
2.2.4 Advantage of Fieldbus System
Fieldbus system has many advantages over conventional point-to-point wiring
and here some of the key ones:
a. Deployment of fieldbus system leads to a significant reduction in wiring,
connections, junction boxes, marshalling cabinets, cable trays, and supports.
This reduction in wiring and connection material is the result of the multi-drop
capability of fieldbus system.
b. The two-way communication enhances additional information such as
calibration and configuration data, diagnostic and test information, device
documentation such as device tag numbers; serial numbers, service history, etc
can be communicated over the network. Equipment maintenance and servicing
become more centralized.
c. The communication of fieldbus is digital and as such the accuracy is not
affected by noise, interference or electrical loading effects.
d. Fieldbus system can be developed and constructed by any vendor because it is
an open standard. It is also interoperable with products from other
manufacturers.
2.2.5 Wired and Wireless Fieldbus Systems
Apart from classification of fieldbus systems in terms of features and
performance, fieldbus can also be classified into wired and wireless standards.
13
2.2.6 Wired Fieldbus
Almost all the fieldbus standards listed in Table 1 are wired fieldbus. Some of
the wired fieldbus commonly used in industrial networking are listed as follows:
a. Foundation fieldbus,
b. Profibus and its variants, and
c. Actuator-Sensor Interface (AS-i).
Wired fieldbuses are more reliable in real-time control of the industrial
process. They are typically used in a process unit containing many flow, pressure,
temperature, level, multivariable, and other instruments, all within a reasonable
distance from each other [13]. The more instruments in a relatively small area,
particularly complex multivariable units, the more a fieldbus makes sense [13].
However, in this thesis, the focus of study on wired fieldbus system is
Profibus.
2.2.7 Profibus
Profibus, which stands for Process Fieldbus, is an open, vendor-independent
fieldbus industrial network standard [8] that was first promoted in 1989 by the
German department of education and research (BMBF), then used by Siemens [13],
and adopted as a part of IEC 61158 in 2000 [13].
Profibus is a Master-Slave type of protocol with an additional tool to allow
multiple masters. In profibus, all devices go through a startup sequence during which
they join the network. Each slave maintains a failsafe timer. If the master does not
talk to it within a certain time limit the slave goes into a safe-state. The master must
14
go through the startup again before further data exchange communication can occur.
It transmits both power and data on the same cable.
2.2.8 Profibus and The Open System Interconnection Layers
The way the technology module of Profibus is designed, it is made compliant
with the Open Systems Interconnection layer reference model (OSI) [14]. In this
case, the communication process between two nodes traverses seven layers. Layer 1,
which is the physical layer, takes care of transmission technology covering the type of
medium, transmission mode and standards. Layer 7, otherwise known as application
layer, deals with the interface among various applications. Figures 3 and 4 show
references between the OSI model and Profibus.
Figure 3 References Between the OSI Model and Profibus [14].
15
Figure 4 PROFIBUS Protocol Communication Architecture [15].
PROFIBUS uses layers 1, 2 and 7 [14]:
• Layer 1 defines the physical transmission. With PROFIBUS, there are copper-
wire versions (RS485 and MBP) and optical and wireless transmission.
• Layer 2 defines the description of the bus access method, including data
security. With PROFIBUS, this is the master-slave method in conjunction
with the token method.
• Layer 7 forms the interface to the application and thus represents the link
between the application and communication. With PROFIBUS, the
communication protocol PROFIBUS DP is used here.
16
• The actual application process lies above layer 7 and is not part of the OSI
model.
2.2.9 Profibus Transmission Technology
RS485 transmission technology is preferred for use with tasks that require a
high transmission speed, but which do not require explosion protection (intrinsic
safety) [14]. This is widely used in the production industry and is also found in parts
of the process industry. The RS485 used for profibus is a twisted, shielded copper
cable. The bus structure enables non-reactive coupling and decoupling of stations and
incremental commissioning of the system [14]. Table 5 shows the overview of the
transmission values [14].
Table 5 Overview of Transmission Values [14].
In an environment with heavy electromagnetic and electrostatic interferences,
or when bridging long-distance optical transmission via fiber-optic cables,
17
PROFIBUS is available. The corresponding PROFIBUS guideline specifies the
technology available for this. Table 6 shows the supported fiber-optic cable types.
Table 6 Supported Fiber-Optic Cable Types [14].
2.2.10 Types of Profibus
Architecturally, Profibus is divided into three main types and they are as
follows:
a. Profibus Decentralized Peripheral (DP)
Profibus DP is a high-speed variant of Profibus protocol developed
specifically for communication between automation systems and decentralized
equipment. It is used in control systems where the access to Input-Output-distributed
devices are deployed. It substitutes the conventional 4 to 20 mA HART systems or in
24 Volts transmissions. It uses the RS-485 physical medium or fiber-optics. It
requires less than two minutes to transmit one input–output Kbyte and is largely used
in critical time controls [15]. Also, in Profibus DP network system, all the input and
output cards are remotely located in the field instead of being installed in the
Programmable Logic Controller (PLC) rack.
18
b. Profibus Process Automation (PA)
This is a variant of profibus used in process automation, where automation
systems and process control systems connect with the field equipment, such as
pressure and temperature transmitters, converters, positioners, and others. It may also
replace the 4 to 20 mA standard. Profibus PA is mostly deployed in hazardous
environments. Profibus PA is also used for connecting PLCs to computers.
c. Profibus Field Messaging System (FMS)
This variant of Profibus is used for communication between Programmable
Logic Controllers (PLCs) and Distributed Control Systems (DCS). It is also used for
interconnecting IEDs in the field for the purpose of exchanging data and messages.
2.2.11 Wireless Fieldbus System
Wireless fieldbus system in industrial network is used as an unguided medium
to transmit electromagnetic wave or signal between transmitters and receivers in the
field [17]. Wireless transmission uses the whole electromagnetic spectrum, which has
a range of 3 kHz to 900 THz [17]. Table 7 below shows the radio spectrum, which
indicates appropriate channels adopted by various wireless technologies. Wireless
fieldbus share the same advantages of wired fieldbus over traditional point-to-point
serial communication system. The benefits of avoiding cabling and associated issues
of cable cuts and the availability of radio technology has encouraged the development
of various wireless fieldbus technologies, which are now utilized in the industrial
network infrastructure.
19
Table 7 Bands in Electromagnetic Spectrum [17].
2.2.12 Types of Wireless Fieldbus
The various wireless technologies adapted in the industrial communication
network are as follows:
a. WirelessHART
Wireless Highway Addressable Remote Transmission (WirelessHART) is the
first Wireless Mesh Network Communications Protocol designed to meet the needs
for process automation applications [8]. It was officially released in September 2007
as part of the HART specification and was a part of IEC 61158. The WHART
specification was approved by the IEC as an international wireless standard (IEC
62591 Ed. 1.0) for wireless communication and process automation in March 2010. It
makes use of Direct Sequence Spread Spectrum (DSSS) channel – hopping scheme
20
based on IEEE 802.15.4 standard, mesh network protocol and retry mechanism to
provide robust and reliable communication [8]. This capability is lacking in other
known wireless communication technologies such as WiFi, ZigBee and Bluetooth.
Figure 5 shows a typical WirelessHART network architecture.
Figure 5 A Typical WirelessHART Network Architecture [17].
In Figure 5 above, there are six devices, which form the wirelessHART
network. They are field device, adapter, gateway, network manager, security
manager, and handheld device.
b. ISA100.11a
This is a wireless sensor network standard developed by the International
Society of Automation (ISA) in 2009. It provides reliable and secure wireless
communication in the field of industrial automation for noncritical monitoring and
control applications. ISA100.11a can integrate with HART, Foundation Fieldbus,
21
PROFIBUS, and others through device adapters, network protocol pass through
tunneling by mapping using interface objects [18]. Network topologies associated
with this standard are Star, Star-Mesh and Full Mesh topologies [19]. A typical
ISA100.11a network architecture is shown in Figure 6 below.
Figure 6 Typical ISA100.11a Network Configuration. (From ISA100.11a-2011
Standard, Wireless systems for industrial automation: Process control and
related applications, 2011.) [19].
2.2.13 Limitations of Wireless Fieldbus System
“WirelessHART and the other available standards such as ISA 100.11a, WIA-
PA, ZigBee, and IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPAN) are mainly made for monitoring applications, and the standards lack a
proper downlink communication channel” [19]. They do not offer deterministic
communication [19]. They all need to be revised in order to enable fast wireless
control applications, which have refresh rates of about milliseconds [19]. In this
project, wireless fieldbus is not used alone. The objective is to use wired fieldbus
(Profibus DP) and also simulate real-time process control via wireless fieldbus
22
communication system using a software (OPNET) and Arduino Wireless Shield as
wireless fieldbus interface to control the network.
2.3 Cloud Technology
Cloud computing is defined as an aggregation of computing power (Central
Processing Unit, Random Access Memory [RAM], Network Speeds, Storage
Operating System software) for delivery as a unified entity to a service over a
network (usually on the internet), rather than physically having the computing
resources at the user or customer location [20]. In the year 2000, cloud computing
was first introduced and now it has become popular. Development of the cloud
computing happened in the first decade of the twenty-first century and reached the
peak of its expectations by the end of the decade. Grid and cluster computing
architectures are the predecessors of the cloud architecture. Figure 7 shows a
schematic of a cloud system.
23
Figure 7 Cloud Computing System [20].
Cloud architecture is based on the aggregation of hardware components that
are accessed and used as a unified entity. The details of the aggregation are hidden to
the user, and thus the complexity of scaling up is negligible.
The pay-as-you-go policy introduced by cloud computing service providers
helps users to scale their service demand accordingly. Cloud computing helps lift off
the responsibility of acquiring powerful infrastructure, operations and maintenance
challenges from enterprises. Figure 8 below shows the building blocks of cloud
computing adopted from the Cloud computing Conceptual Reference Model of
National Institute of Standard and Technology (NIST) Cloud Computing reference
architecture published in the NIST Special Publication 500-292 [33] and defined in
NIST 800-145 [34].
24
Figure 8 Building Blocks of Cloud Computing System [27] (adopted from the
Cloud computing Conceptual reference model [33][34]).
2.3.1 The Cloud Computing Service Delivery Model [20]
a. Software as a Service (SaaS)
SaaS model allows using software applications as a service to end-users. SaaS
is a software distribution model in which applications are hosted by a vendor or
service provider and are made available to customers over a network (internet). SaaS
is becoming an increasingly prevalent delivery model as underlying technologies that
support Service Oriented Architecture (SOA) or Web Services. Through internet, this
service is available to users anywhere in the world [20].
25
b. Platform as a Service (PaaS)
This is the model, which provides platform and environment for developers to
build applications and services. This service is hosted in the cloud and accessed by the
users via internet [10].
c. Infrastructure as a Service (IaaS)
This is the infrastructure that provides access to computing resources and
services in a virtualized environment on the internet. It provides computing
infrastructure such as virtual server space, network connections, bandwidth, load
balancers, and internet protocol (IP) addresses.
2.3.2 Cloud Computing Deployment Model [27][33][34]
Four deployment models are defined in NIST definition of cloud computing,
and they are as follows:
Public Cloud
This is cloud computing system provided to clients by a third-party service
provider through the internet. The service provider charges users as per the resources
they nominate to access and utilize. Although it is public, each user’s data and
allocated resources are not made visible or transparent to other users.
a. Private Cloud
Private cloud computing system is built, operated and maintained by a private
enterprise, exclusively for its own business and operation. There are two variations of
this deployment model [35]:
26
1. On-Premise Private Cloud [35] – This is a private cloud sited in the data
center of the owner-enterprise. It is also called internal. This model provides a
more standardized process and protection, but is limited in aspects of size and
scalability. The capital and operational costs for the physical resources is
borne by the owner. This is best suited for applications that require a complete
control and configurability of the infrastructure and security.
2. Externally Hosted Private cloud [35] – In some instances, some
organizations do want to have private cloud hosted in their data center, but
externally with a cloud provider, where the provider facilitates an exclusive
cloud environment with full guarantee of privacy. This is best suited for
enterprises that neither prefer a public cloud due to sharing of physical
resources, nor totally acquire and host the cloud computing system due to risk
and lean operational resources.
b. Community Cloud
This is a type of cloud deployment model in which the cloud is controlled and
used by a group of organizations that have shared interests, such as specific security
requirements or a common mission [27][33][34]. The members of the community
share access to the data and applications in the cloud.
c. Hybrid Cloud
This a combination of both the private and the public cloud computing system
deployment models. In this type of model, the objective is to provide the users the
opportunity of outsourcing non-business-critical data, information and processing to
the public cloud, while keeping business-critical services in the private cloud.
27
2.3.3 Characteristics of Cloud System
Cloud system has five main characteristics defined by the NIST, which have
since been redefined by number of architects and experts [26]. The inherent features
of the cloud system make it attractive to businesses, manufacturing and process
industries with multiple regional operational locations. These key characteristics are
shown in the essential characteristics section of Figure 8 given above.
a. On-demand Self-service [27]
This characteristic feature enables consumers to allocate computing
capabilities and services for themselves without human interaction of the service
providers.
b. Broad Network Access [26][27]
Network and access capabilities are available in cloud computing system
through standard mechanisms that promote its use in heterogeneous thin or thick
client platforms such as mobile phones, laptops and PDAs [26].
c. Resource Pooling [26][27]
Multiple users have the ability to concurrently or simultaneously utilize
computing resources pooled together by the service provider to serve multiple
customers, with different physical and virtual resources dynamically assigned and
reassigned in accordance with the customers’ demand.
d. Rapid Elasticity [26][27]
Computing resources, storage and network resources provided to customers
are made elastic in such a way that they can automatically expand outward and
inward in line with customers’ needs.
28
e. Measured Service [26][27][28]
The metering capability of cloud systems automatically use inherent metering
service to control and optimize resource use, appropriate and tailored accordingly to
the type of service. Resources such as storage, processing, bandwidth, and active user
accounts are controlled by the metering capability of the cloud system.
2.3.4 Issues with Cloud System
Despite the great attractive characteristics of the cloud system, it has some
issues that hinder its efficiency in real-time industrial process control. These
limitations are explained as follows:
a. Latency and jitter issues [29]
Latency or delay in cloud system manifests in two similar modes – delay in
the provisioning of resources and delay in resources accessibility due to internet
network issues. Manufacturing and industrial process control require reliable,
uninterrupted, high-speed communication [29] between central control and field-end
devices to ensure optimal quality control and timely process safety interventions. This
cannot be guaranteed in cloud system, which uses the internet as its communication
backbone
b. Bandwidth limitation
When customers have multiple resources, applications, locations or sites and
field-end devices to monitor and control, availability and allocation of bandwidth
becomes a big issue, no matter the type of network topology adopted.
29
c. Security issue
The public cloud is not to be totally relied upon for transmission of monitoring
and control data for industrial process because any security breach could disrupt
services
2.4 FOG Computing Technology
The term fog computing, coined by Cisco in 2012 [21], refers to the need for
bringing the advantages and power of cloud computing closer to where the data is
being generated and acted on. Fog computing reduces the amount of data that is
transferred to the cloud for processing and analysis, while also improving security, a
major concern in the IoT industry [22]. In industrial process automation, its
applications are made possible in an architecture and implementation of industrial
automation by enabling servers and other intelligent devices with data processing
capabilities to process raw data close to the source from field devices such as sensors,
transmitters and cameras before the data is transmitted to the cloud. Fog technology is
also called Edge technonlogy [39].
A fog-computing strategy provides decentralized computing by bringing the
intelligence of the cloud closer to the end devices. It is one of many options that
machine builders and factories are presently considering. A central server requires
high costs for hardware and software, and fog computing services offer new
possibilities and connectivity options. Local data processing captures more process
data but requires data transport, exchange, storage, analysis and security.
30
However, the objective of fog computing system is to reduce the amount of
data that needs to be transmitted to the cloud for processing, analysis and storage,
while providing timely and real-time response or interaction with intelligent or smart
field-end devices. The fog stack gets data from sensors to the machine controller, and
performs analytics locally. This way latency, which is a huge challenge in cloud-
based real-time control, would be drastically reduced.
2.4.1 Software Architecture of Fog Technology
The software architecture of fog technology hinges on key components of fog
computing technology as shown in Figure 9 below.
Figure 9 Components in Fog Software Architecture [39][40].
a. Heterogeneous Physical Resources [39]
31
Fog nodes are heterogeneous in nature. They range from high-end servers,
edge routers, access points, set-top boxes, and even to end devices such as vehicles,
sensors, mobile phones, etc. Different hardware platforms have varying sizes of
random access memories, secondary storage capacities and platforms to support new
functionalities. Also, different platforms run different operating systems and software
applications, leading to various hardware and software capabilities.
The Fog technology, which is heterogeneous in nature would also have
network infrastructure that is heterogeneous in nature. The range of network platform
is from high-speed links, which connect enterprise data centers and the core to
multiple wireless access technologies such as 3G/4G, LTE, WiFi and other similar
technologies toward the edge.
b. Fog Abstraction Layer
This layer provides uniform and programmable interface for seamless resource
management and control. It also provides generic Application Programming
Interfaces (APIs) for monitoring, provisioning and controlling physical resources such
as CPU, memory, network and energy.
c. Fog Service Orchestration Layer
This layer performs the following functions:
1. Provides dynamic, policy-based, life-cycle management of Fog services.
2. It manages services on a large volume of Fog nodes with a wide range of
capabilities achieved with the following technology and components:
o Foglet Software Agent
o Distributed Database
o Policy-Based Service Orchestration
32
2.4.2 Fog Hierarchy of Operation
The fog hierarchy of operation is a system-level operation architecture that
migrates elements of computational capability, networking and storage gradually
from the cloud through to the edge of the network. Figure 10 below shows typical
operation hierarchy of fog system derived from the concept of bringing data
computation closer to the local intelligent devices called fog nodes or edge devices.
Figure 10 Different Uses of the Same Data [25].
Fog node takes data produced by local embedded devices and sensors,
processes it, stores part of the data and transmits required part to the cloud for usage
in the enterprise level. The first tier of the architecture is used for Machine-to-
Machine (M2M) interactions and supports real-time applications. In this, the first-tier
local server or the fog node preprocesses data from the field-end devices and passes
them on to the higher tiers for further processing, storage and transmission to the
cloud. This concept is known as hierarchical data processing [25][32]. The M2M
33
interaction is the key aspect toward increasing the intelligence of Smart field devices
[26, 27]. When the above architecture is utilized, fog is capable of providing sub-
seconds responses [28].
In [29], fog computing is used for one of the most computationally intensive
tasks, namely, brain-state classification, where it achieves low response times to
enable augmented brain–computer interaction [25].
The second and third layers of the fog architecture also deal with M2M
interaction, real-time analytics, visualization and reporting, for example, human to
machine (H2M) interactions. The second layer provides seconds to sub-minute
responses. Consequently, the second layer can handle soft real-time tasks, M2M
interactions and H2M interactions. The last layer is responsible for analytics. It
provides response times from minutes up to days for transactional analytics. Two
different architectural concepts regarding the third layer can be developed:
independent fog devices connected with the cloud and interconnected fog devices
(smart grids) to exploit the advantages of cooperation [25][30][31]. It should be noted
here that the higher the tier, the wider the coverage range.
34
Figure 11 Analytics for Fog Computing. Credit: Cisco [43].
2.4.3 Characteristics of Fog Computing
Fog computing has some characteristics, which makes it important for real-
time application. These features are explained as follows [36][37]:
a. Edge location, location awareness, and low latency
Fog technology from inception is intended to support endpoints with rich
services at the edge of the network, including applications with low latency
requirements such as gaming, video streaming, and augmented reality. Video cameras
are now used in parking lots, buildings and other public and private spaces to increase
public safety. The sheer bandwidth of visual (and other sensor) data being collected
35
over a large-scale network makes it impractical to transport all of the data to the cloud
to obtain real-time insights. Proximity to the edge devices, computing power, storage
and use of fieldbus technology enhances speed of data transmission.
b. Geographical distribution
The services and application target of fog technology are widely distributed.
Therefore, the data gathered from field-end devices are distributed through fog nodes.
Proxies and access points, which are part of fog network play a key role in making
sure high-demanding signals such as video are distributed beyond the local vicinity
without latency.
c. Support for mobility
Fog applications support and enable the use of mobile techniques such as
Locator/ID Separation Protocol (LISP) to communicate with mobile devices [38],
decoupling of device identity from location identity and requiring distributed
directory system.
d. Real-time interactions
A key feature of fog is the capability for real-time interaction with field-end
devices rather than batch processing.
e. Heterogeneity
Fog technology can adapt and can be adapted to a wide range of
environments. Fog nodes come in different form factors and can be deployed in any
network environment.
f. Interoperability and Federation
Fog computing system has the ability to seamlessly support certain services-
driven variety of communication protocols as deployed by various service providers.
36
g. Large-scale sensor networks
The applications, protocols and resources associated with fog computing
enables it to support large number of sensor networks.
h. Support for on-line diagnostic and interplay with the Cloud
2.4.4 Fog Nodes
This is the fundamental element of fog computing, which is the collection of
modular hardware and software elements that can be configured to perform the
specific functions required at various levels of the network hierarchy by the mix of
Internet of Everything (IoE) applications the network is expected to support [41]. The
higher the fog node position in the network hierarchy, more sophisticated the
hardware and software configuration and performance. The fog nodes that are lower
in network hierarchy or closer to the field-end devices have relatively simple
hardware and software configurations and modest performance specifications,
whereas those that are higher in the network hierarchy or closer to the cloud have
more sophisticated and advanced performance close to those of high-end servers and
high bandwidth networking equipment [41].
In terms of hardware configuration, Fog nodes can be categorized into single
board configurable platforms and high-capacity modular platforms [41][42]. There
are different ways Fog nodes can be implemented. They can be deployed on
traditional network elements such as routers, servers, storage engines, appliances,
gateways, edge devices or access points, or as stand-alone fog boxes.
37
Fog nodes can be scaled to any form factor, memory, network performance
and persistent storage size. They can also adapt to many different deployment
environments.
In terms of software configuration, fog nodes are highly virtualized machines
with multiple virtual machines running under a highly capable hypervisor. That
hypervisor includes real-time enhancements and security extensions needed to serve
the needs of critical fog applications.
2.4.4.1 How Fog Nodes Operate
This provides a summary of how the Fog nodes operate. The summarized
system of operation is as follows:
• Fog nodes receive feeds from intelligent or smart field devices or IoT
devices using any protocol, in real time.
• The Fog nodes then run IoT-enabled applications for real-time control and
analytics, with millisecond response time.
• The Fog nodes later provide transient storage for processed data, often 1–2
hours.
• Finally, they send periodic data used for developing business intelligence
to the cloud and utilize command and control information for real-time
industrial process control.
2.4.5 Comparison between Cloud and Fog Computing System
This section examines the differences between cloud computing and fog
computing so that cloud characteristics have very severe limitations with respect to
quality of service (QoS) demanded by real-time application requiring almost
immediate action by the server or real-time control of the industrial process. Tables 8
38
and 9 present the contrasting characteristics of fog or edge computing against cloud or
core computing.
Table 8 Requirement Comparison Between Fog and Cloud Computing.
Requirements Cloud Computing Fog Computing
Latency High Low
Delay jitters High Very low
Location of service Within the Internet At the edge of local network
Distance between client and server
Multiple hops One hop
Security Undefined Can be defined
Attack on data enroute High probability Low probability
Location awareness No Yes
Geo-distribution Centralized Distributed
Number of server nodes Few Very large
Support for mobility Limited Supported
Real-time interactions Supported Supported
Type of last mile connectivity
Leased Wireless
39
Table 9 Contrasting Cloud and Fog Computing.
Cloud Computing Fog Computing
Data and applications are processed in a cloud, which is time-consuming for large data
Instead of processing and presenting from a centralized cloud, fog operates on the network edge. So, it consumes less time
There is a problem of bandwidth clogging due to frequent transfer of every bit of data over the cloud channels for processing
There is less demand for bandwidth because every bit of data is aggregated at certain access point instead of sending of the cloud channels
Slow response and scalability problem as a result of servers that are located remotely
By setting small servers called edge servers or local cloud in the proximity and visibility of users and intelligent or smart devices, it possible for fog computing to have smaller response time and avoid scalability issues
2.4.6 Local Automation Cloud [7][55]
“Local cloud is defined as a number of IoTs within a physical proximity” [55].
The Arrowhead project developed the concept of local automation cloud [7][55] to
ensure interoperability and issues of the IoT, especially in the automation domain are
resolved [7][56]. The concept is also geared toward ensuring that IoT or edge of field
devices utilize Service-Oriented Architecture (SOA) to provide comparable services
being provided by the global cloud in addition to ensuring quality of service and real-
time automation application activities [7][55]. In this project, local cloud system is a
server, which is integrated in the closed loop control network, which is part of the
LAN. The local cloud idea is to let the local cloud include the devices and systems
required to perform the desired automation tasks. So, providing a local room that can
40
be protected from outside activities. Fog nodes, edge nodes and local automation
cloud are all geared toward migrating global cloud functionalities to the field or edge
level. Figure 12 shows the Arrowhead Local Automation Cloud.
Figure 12 Arrowhead Local Automation Cloud [55].
2.4.6.1 Local Automation Cloud Properties
The Arrowhead Framework local cloud have provided a number of properties
important to automation. There are some of the properties that are related to cloud
technology are part of them, while others are related to real-time, engineering,
security, scalability and functionality. These properties are summarized as follows:
a. Self-contained
There are no external resources needed to establish the local cloud. This
property allows local operation to be independent of external resources. This feature
ensures that local cloud has the capability of creating a closed cloud boundary. This is
the reason why a local automation cloud is proposed to have [7][55][57]:
41
• Device, system and service registry, which perform the following
functions:
- Allowing of discovery of devices and keeping of tracks of devices,
software systems and services deployed within a local cloud using
registry [57].
- Provision of data on which systems are registered with a local cloud,
metadata of these registered systems and the services these systems are
designed to produce or consume. This function is carried out using the
service registry.
- The provision of a unique device identity and metadata using device
registry.
• Service orchestration: This aspect of local cloud property enables it to
perform the following functions:
- System-of-System (SoS) run-time configuration
- Provision of orchestration rules, which define service produced by a
particular system is to be consumed by another particular system.
• Service authentication and authorization. This property of local automation
cloud enables it to carry out the following functions:
- Provision of authentication of service consumers and authorization for
service consumption.
b. Automation support [55][57]
• Support for automation system design, configuration, deployment,
operation and maintenance
• Enabling event-based information exchange
• Enabling information exchange audit
• Support for communication QoS
c. Provide a security fence to external networks [7][55][57]
• Secure bootstrapping and software update
• Support for device, system and service metadata
• Support for protocol and semantics transparency
• Support for secure administration and data exchange with external
resources
42
d. Interoperability between systems [57]
“This property provides a structure for information on interfaces, service
protocols, methods, datatypes, semantics, encoding, and compression provided by a
service producing system within the local cloud. Based on these, service consumers
can be properly matched with service providers. Furthermore, through protocol and
semantics translation devices/systems featuring different service protocols, semantics
and encoding can be made interoperable.” [57]
e. Inter-cloud service exchange [57]
This is the property that enables inter-cloud service exchange by ensuring that
service exchange administration such as service discovery, authorization,
authentication and orchestration becomes possible between local clouds.
f. Security
Security property ensures the following functions happen in the local cloud
system:
• Provision for authentication of a service consumer, authorization of service
consumption and protection of payload data.
• Provision of methodology for the secure deployment of devices, systems and
services
• Provision of methodology for secure software update.
2.4.6.2 Mandatory Core Services and Systems
In order to establish local automation cloud, the following mandatory core
services and systems are required:
a. The Service Registry system
• This system enables publication service instance(s) by a service
provider
43
• It also provides a service consumer the capability to find or discover
what service instance(s) it desires to consume.
b. The Authorization system
• Enables a service provider to determine which consumer(s) to accept.
c. The Orchestration system
• Enables remote control (orchestration) of which service instance(s) a
consumer shall consume.
Figure 13 Arrowhead Core Systems and Their Use.
2.5 Communication Levels in an Industrial Plant
Making industrial processes smarter and more efficient to respond to
customers’ needs and produce high-quality products at reduced cost in a safe manner
requires real-time control of the present day complex industrial processes. This leads
to increase in the number of instruments and the quantity of data being transmitted
and retrieved from field devices. To achieve real-time control of industrial process
44
requires handling data, voice, video, and command and control signals. This puts a lot
of demand for communication in the industrial environment.
Industrial communication is divided into three levels; namely, cell, field and
sensor levels. This is shown in Figure 14 below.
Figure 14 Different Communication Levels in a Plant.
The communication can be vertical as well as horizontal within a level. At
sensor/actuator level both communication and power signals are transmitted in the
same cable. Communication at this level is by binary signals. The field level contain
devices such as transmitters, drive units and Input/Out modules. Some devices at the
field level, such as transmitters transmit limited amount of data and can be powered
via bus, while others like drivers transmit a lot of data and are powered by an external
power source. Process stations are found at the cell level and they transmit very high
volume of data. However, data transmitted by equipment or process station at the cell
level are not as time critical as data transmitted by devices in the sensor and field
Levels. This is why in the thesis, attention is focused on fieldbus devices and local
cloud, which operate at the field level and the sensor or actuator levels. All fieldbuses
studied in this thesis operate at the field level.
45
Figure 15 ISA95 Architecture of Automation Systems (adapted from [53]).
2.6 Related Work
The use of cloud computing in industrial automation is not a completely new
idea. But most of the existing works focus on higher levels than at the field level. At
the enterprise level, where centralized data centers operate, cloud computing is used
for data analytics useful for building business intelligence [44–46] as depicted in
Figure 15 above. However, very little work is done so far that involves cloud
computing within control loops in the industrial automation [45], [47]. The issue of
46
Networked Control System (NCS) has already been worked and resolved in several
studies [48], [49]. The following options were taken in resolving the issue:
a. Use of various tuning procedures in NCS to tune the controller to compensate
network delays or data dropout [50]. In the case of this study, the local tuned
controller moved to the local cloud or fog system and delay mitigation
mechanisms are utilized on the actuator-sensor side [50].
b. Studies done by Hegazy et al. [51] also proposed a delay compensator based
on a smith predictor to mitigate the delays of a remote server. However, the
smith predictor is a model-based predictor, but in this study the goal is to have
a simple mitigating mechanism on the edge device side that IoT devices can
work with. This study is geared toward investigating the cases, where the
delays are considerably longer than the sampling period.
2.6.1 Cloud Computing for Industrial Automation Systems
The desire to make manufacturing and industrial process flexible and smart
has led to building intelligence into sensors, transmitters and other field devices.
Vogel-Heuser et al. [80], proposed a new architecture as global information
architecture for industrial automation. This newly proposed automation architecture
consists of two main layers shown as two cones, which are placed between business
and technical processes. In this new automation hierarchy, the lower layer represents
the migration of field and control layers in traditional automation hierarchy pyramid
including devices and functionalities, while the upper layer represents the process
control and management layers on top of the control layer in the automation pyramid
[80]. Omid Givehchi and Jurgen Jasperneite [81], in their paper titled “Industrial
Automation Services as part of the Cloud: First Experiences,” [82] presented a
solution on the use cloud computing to reengineer the current automation architecture
or hierarchical automation pyramid, which was proposed by Vogel-Heuser et al. [81].
In their solution, as shown in Figure 16 below, special automation functions and
47
services postulated directly as cloud technology SaaS from the IT-cloud as well as
Automation-Cloud (AT-Cloud). The alternative to this is the use of Platform as a
Service component (PaaS) of the cloud computing technology as an automation
platform to deliver specific needs for integration, for example, process logs and plug
and play parameters.
As shown in Figure 16, AT-Cloud is offered to provide functions and services
at lower levels and IT-Cloud hosts applications and services in upper levels of the
automation [81].
Figure 16 Global Information Architecture With the Use of Cloud Computing
[82], Based on [80].
The combination of both IT-cloud and AT-Cloud was proposed as Information
Model [81]. Therefore, the integration of both IT-cloud and AT-Cloud can be
replaced by using Everything-as-a-Service (XaaS) cloud system component, which is
48
represented by a single cloud system called a cyber-physical system (CPS). The
integration between the cloud and real devices can be enabled by encapsulating
services and functions inside delivery standards. Omid Givehchi and Jurgen
Jasperneite [81] proposed a replacement of the IT-Cloud and AT-Cloud with SOA
known as XaaS for automation, as shown in Figure 17 below. The implementation
proposed is Control as a Service (CaaS) component of cloud system.
In actual implementation, the team decided to use Azure-based private cloud
system to develop cloud-based control system. The proposed implementation could
not achieve determinism because generic cloud hypervisors have no support for real-
time applications, and also internet-based system of communication suffer from
latency.
Figure 17 Cloud-Based Architecture for Industrial Automation [79].
2.6.2 Analysis of Profibus-DP Network Delay
In 2005, Dr. TAO Jun, WANG Zhan-lin [83] of the School of Automation
Science, Beihang University, Beijing carried out a study on Profibus-DP network
49
delay and how it influences control and presented his findings in a paper titled
“Analysis of PROFIBUS.DP Network Delay and Its Influence on the Performance of
Control Systems” [80]. The segmented data transmitted in the Profibus-DP network
into system data and user’s programming data, data of configuration of the system
and the other part of system states data. The system data, which are data from sensors
and transmitters, are classified as real-time and high-priority data, while user’s
programming data, data of configuration of the system and the other part of system
states data are classified as non-real-time and low-priority data [83]. This
classification helps in the calculation of data transmission delay in a Profibus-DP
network. The summary of the work is that Profibus-DP network handles real-time
data transmission better than other types of network because it uses both classification
and prioritization of various types of data. In the Profibus network, high-priority data,
which are the real-time data, are first handled no matter their sizes and how long it
takes to transmit them. This is why, latency and jitters are minimal in Profibus-DP
network.
50
CHAPTER 3. RESEARCH METHODOLOGY
3.1 Introduction
In order to study the characteristics and challenges of real-time
communication in industrial systems, modelling and simulation of real industrial
systems approach is adopted. This approach has long been utilized by researchers,
analysts, designers and other professionals for ease of experimentation and studies of
physical and non-physical behaviour of systems and processes to enhance
advancement in technology, application and response to challenges [54]. Simulation
is used to represent the real-life situation in which servers, WANem, Control system
unit and simulate control signal from the local cloud server web-interface to control
the control system unit. Software applications and laboratory models are used to
create an ideal environment for the demonstration of real time of the industrial
process through local cloud. Profibus-DP Master Simulator is a typical simulator used
in this research project to mimic fieldbus communication system.
This simulation study has been divided into nine steps enumerated as follows [54]:
a. Problem formulation or definition [54][59]
b. System definition [59]
c. Model construction [54]
d. Input data collection and analysis [59]
e. Model translation and programming
f. Verification and validation [59]
g. Design of experiment
h. Experimentation or simulation and analysis [59]
i. Documentation and implementation [54][59]
51
The flowchart shown in Figure 18 below represents these steps.
Figure 18 Flowchart Representing Typical Steps and Decisions for Conducting a Simulation Study [59].
3.2 Problem Formulation or Definition [54][59]
This thesis started with the formulation of the research problem statement,
which provides the goal and the conceptual framework of the study. The solution to
the real-time control issue of latency encountered on Ethernet and internet-based
platform is the main objective leading to the formation of the conceptual framework
of this study. The approach adopted is to carry out a comparative performance
analysis between Profibus-DP, which is a well-known effective fieldbus industrial
communication standard, and the emerging local cloud technology. Experimentation
52
and simulation of real-time control of a control process using these variables provides
a platform for data collection. The goal in this phase is to compare the effectiveness
of real-time control through local cloud on one aspect and Profibus-DP on the other
aspect to recommend a reliable communication and control standard free of delay and
jitters.
3.3 System Definition [59]
In this phase, a high-level definition of the system architecture is provided.
This step also specifies the system parameters to determine the requirements for the
simulations to investigate issues with real-time control through cloud system. The
requirements are made quantitative and measurable to enable evaluation in the last
phase. The different parts of the architecture must be identified as well as their
functionalities [25]. The detailed system requirements and components are given in
Section 4, where the system architecture is presented in detail. The dynamic
interactions between the different components should be specified as well. All
constraints and assumptions are also stated in this step.
3.4 Model Construction
This part defines the structure, behavior and views of the experimental
platform architecture. This is also referred to as model formulation. The structure of
the system here is a control-loop set up in a control network. A server, which has
capabilities of data collection, computation, processing and storage is deployed to be
a component in the closed control loop as depicted in Figure 19 below.
53
Actuator Process Sensor
Controller
LAN/WAN
Figure 19 Block Diagram of NCS [25].
In this thesis, to carry out effective real-time control performance comparative
analysis, two different closed-loop control systems are modelled for this study and
they are:
a. Ethernet-based closed-loop control system model
b. Profibus-DP closed-loop control system model
3.4.1 Ethernet-based closed-loop control system model
The Ethernet-based closed-loop control system model involves the connection
of a Web Server, Ethernet switch, Computer running Network monitoring Software
(WANem), Arduino UNO control system with input/output modules, temperature
sensor and multi-colour light-emitting diodes (MLED). The Arduino is programmed
to switch the MLED ON and OFF through a web program in it and a web interface
provided by a computer used as a Web Sever. The Arduino controller, its program,
and its input/output devices represent the industrial control process. The Web server
represents the local cloud, through which ON/OFF real-time control command is
passed to the Arduino control system. The Network monitoring system running
WANem software application (WANem from TATA Research Centre, India) is used
54
for setting and monitoring latency and jitters. The configuration of static route in the
Web server helps direct all communication and control traffic to the Arduino through
WANem server.
3.4.2 Profibus-DP Control system model
To simulate real-time closed-loop control from a Master Control system using
Profibus-DP communication protocol, HMS/Anybus Profibus Master Simulator is
connected to a slave control via serial communication system using a profibus
converter with RS232 to RS485 converter to connect to a control system.
3.5 Input Data Collection and Analysis [59]
The availability of data about the system is of great importance in the
construction of its model. This step ensures that the type of data to be collected is
dependent upon the objective of the study. The construction of the simulation model
and the collection of data have a constant relationship. Therefore, the type of data and
the amount of data may change as the model develops. Data is required as inputs to
the model and for validation of the model [59]. The data collection experiments are
performed on two different models – real-time industrial process control through local
and through Profibus-DP communication standard. In this study, the data collected are
data transmission delay (latency) and variation (jitters). On one aspect, these data are
collected real-time when the replica of industrial control process (Arduino Control
system) is controlled through modelled local cloud (Web server and WANem) in a
local control network. On another aspect, similar data are collected when the replica
of industrial control process is controlled via a Profibus-DP communication modelled
system. The data collected from these two simulation processes, which form the
results of the experiments are compared as input data to the study in order to arrive at
55
a reasonable conclusion, which would produce recommendations for system
improvement in real-time industrial control processes.
3.6 Model Translation and Programming
In this step, the model is translated into programming, which is a computer
recognizable format [54]. There are many general and special purpose simulation
languages used in writing simulation programs. In this study, WANemand Profibus
Master Simulator are special-purpose software simulation programs utilized.
3.7 Verification and Validation [59]
The purpose of this step is to ensure that the model would do exactly what it is
built for, to represent in terms of the system characteristic behavior. Verification is the
process of ensuring that the model behaves as intended, usually by debugging and
cross-checking all setups. In this study, verification and validation are achieved
through trial simulation runs. When the real-time control is performed through local
cloud and Profibus Master Simulator, respectively, the results of the trial simulation
runs are compared with established standard real-time responses, respectively.
Settings are adjusted and fine-tuned and the trial simulation runs are repeated until
benchmarked standard response is achieved. Then, the actual experiment would
commence.
3.8 Design of the Experiment
We used simulation to experiment the model. To make results reliable, it is
important to design simulation experiment to obtain results within some specified
tolerant limits and at a reasonable level of confidence [54]. This is what is designed to
achieve in this phase.
56
3.9 Experimentation or Simulation and Analysis [59]
In this phase, the deployment of alternative models is involved, which would
serve the purpose of validation of real-time control performance in both the Ethernet-
based model and the Profibus-DP industrial communication model. As stated earlier,
real-time control via local cloud and through Profibus communication network are the
two alternatives. Here, we used simulation runs and statistical methods for comparing
the performance of alternative systems with that of the real system [59].
3.10 Documentation and Implementation [54][59]
In this last phase, simulation program procedures are documented for use in
similar situations in the future. The documented program can also be modified and
used for different systems. Documentation consists of the written report and or
presentation. It allows the user to change parameters of the model at will to
investigate the influence on the outputs, to find combinations that can give optimal
results and performance. Discussion of the implications of the results of the study is
carried out based on the results obtained. The best course of action is identified,
recommended, and justified.
The implementation aspect involves setting up of the instruments and model to
provide input interface, processing unit and output interface. Trial simulation runs are
necessary for the perfection of the setup process.
57
CHAPTER 4. EXPERIMENT SETUP AND THE SIMULATIONS
4.1 Introduction
In this chapter, the model prototype, experimental setup, and the simulations
details are presented. In the first instance, this chapter presents the model system
architecture. Then, it gives a detailed description of the model system components
and their specifications. It also provides a step-by-step experiment procedure. The
simulations and results are presented at the end of this chapter.
4.2 Model Systems Architecture Overview
In this section, the goal is to explain the model system architecture we adopted
in the investigation of performance comparison between local cloud and Profibus-DP
in real-time industrial process control. To achieve this, we set up two systems models
– one for local cloud performance in industrial communication and the other for
Profibus-DP performance investigation in real-time industrial control.
4.2.1 Model System Architecture for Local Cloud
Figure 20 Networked Control System [25].
58
The addition of a remote server to a control loop can introduce latency, jitters
and packet loss. Figure 20 shows that the controller is connected to the sensors and
the actuators either through LAN or WAN [25]. When the controller is connected to
the sensors and actuators through a LAN, the remote server is regarded to be a local
cloud or fog node, which is located close to the control loop. But when it is connected
via a WAN, it is considered to be a cloud, which results in so much latency [25]. To
model this NCS and carry out real-time control performance evaluation, we represent
this NCS here with a control system model architecture shown in Figure 21 below.
Figure 21 Ethernet-Based Local Cloud Architecture Overview [25].
Real-time control command is issued from a Web server in the private cloud
through WANem or local area emulator () to the Arduino, which is a model of the
control system. WANem, which can be used for either LAN or WAN emulation is
utilized to set latency, jitters and packet loss parameters. The response is monitored in
59
the web server using Internet Control Message Protocol (ICMP) network monitoring
method.
4.2.2 Model System Architecture for Profibus-DP
In the case of Profibus simulation in this study, Profibus Master Simulator
from HMS Anybus [60] is used as the master, while Arduino Mega 2560 with its
input/output modules is used as the slave. The Arduino Mega 2560 has the same
program as in the case of the local cloud. The difference here is that RS485 shield is
attached to the Arduino Mega 2560 to provide a serial interface for connection to the
Profibus-DP network. The Profibus Master Simulator installed in Dell Latitude E6230
is Windows 7 Professional Service Pack 1 [61] with a docking station to ensure
provision of COM port for serial connection between the Profibus Master Simulator
and the Arduino Mega 2560. The operating system running in this Dell Latitude
E6230 is Windows 7 Professional Service Pack 1. The processor handling all data
processing and computation is a fourth-generation 2.9 GHz Intel Core i5-3380M
processor [62]. To ensure protocol translation between the Profibus Master Simulator
and the Arduino Mega 2560, we used BradCommunications TM Profibus gateway,
Brad DRL-DPS-SRM Direct-Link Gateway Profibus-DP Slave to RS232/485 Serial
Master/Slave [63] to connect to a serial-to-Ethernet media converter [64].
To ensure a proper operation of the Arduino Mega 2560 serial
communication, an Arduino Mega 2560 RS485 library is uploaded to the Arduino
through the Arduino IDE version 1.8.4 installed in the computer (Dell Latitude
E6230).
60
Figure 22 Profibus-DP Simulation Model.
4.3 Design of System
As explained in the Section 4.1 above, since there are two model system
architectures, there are also two separate systems designed to reflect the models – the
local system for real-time control and the Profibus-DP master and slave system.
4.3.1 Model system components and their specifications
4.3.1.1 The Local Cloud System
In this section, we provide the details of specifications and requirements of the
major components (both the hardware and software components) of the model of the
local systems used in this study.
61
4.3.1.2 Arduino Mega 2560
The Arduino Mega 2560 kit is used as the end device to handle real-time tasks
like a process automation system. The Arduino model control system comprises both
hardware and software. The hardware used in this study is composed of an assembly
of an ATMega3288 microprocessor, prototype board, Ethernet Shield, RS232/RS485
Serial Communication Shield, relays, sensors and LEDs.
Hardware of the Arduino System
The hardware for the control system model is shown in Figure 23 below. The
hardware of the control system model built with Arduino comprises the following:
a. Vilros Ultimate Starter Kit [69], which has Arduino Mega 2560, Arduino and
Breadboard Holder including a breadboard.
b. Ethernet Shield for Arduino Mega 2560 – This unit enables the Arduino to be
connected to the Ethernet network. The picture of the Ethernet shield is shown
in Figure 24 below.
c. RS232/RS484 shield for Arduino Mega 2560 Rev 3 – This is a serial
communication interface module, which is fixed unto the Arduino Mega 2560
board. The picture is shown in Figure 25 below.
Figure 23 Arduino Mega 2560 Control System Model.
62
Figure 24 Arduino Mega 2560 Shield.
Figure 25 Arduino Mega 2560 RS-232 / RS-485 – Hardware [70].
Software for Arduino System
The Software comprises of Arduino IDE version 1.8.4 [65] and libraries used
in this model design are as follows:
63
a. OneWire Library [66]
This is a library, which provides routines for communication through the
Dallas OneWire protocol; for example, with DS18B20 digital thermometer used in
this study. OneWire is a Master/Slave protocol, and all communication cabling
required is a single wire. It is possible for slave devices on the OneWire bus to even
get their power supply from data line [67].
b. Dallas Temperature library [66];
This library is for temperature control in Arduino Mega 2560 control system
program. It also enables measuring of temperature utilization of DS18B20
temperature sensor, which is used in this thesis study.
c. Hardware Serial RS485-master [66]
This library supports the use of an RS485 transceiver connected to the
Universal Synchronous and Asynchronous Receiver and Transmitter (USART)
(Tx/Rx pins) in a half-duplex, concurrent multi-drop (that is, multi-master, multi-
slave) environment. For this purpose, the software suite provides capabilities for
message addressing and filtering as well as collision detection and collision avoidance
[66].
d. Ethernet Library for Arduino
This library enables the use of Arduino Ethernet (shield or board) to connect
to the internet. It provides both client and server functionalities. And it also enables
the connection of Arduino to local network also with Dynamic Host Configuration
Protocol (DHCP) and to resolve Domain Name Service (DNS) [68].
64
e. Control System Software Program
The control system software program is a C program of Arduino Ethernet
Web server [69] used to control relay and also monitor temperature of the
environment.
4.3.1.3 Computers
In this study, to model the local cloud system, two computers were used. Their
specifications are stated below:
a. Dell Latitude E6230 laptop – The operating system of this computer is 64-
bits Windows 7 Profession version Service Pack 1. Its processor is Intel Core
i5 with 2.9GHz clock speed. Its random access memory is 4 Gb. The web
server for this study is built in it. It is also used to monitor and record network
traffic parameters. This Web server is a model of the local cloud within a
LAN.
b. HP Desktop Computer – This computer is equipped with Intel Dual-Core
processors. Its operating system is also Windows 7 Profession version Service
Pack 1. This computer is used to run the WANem version 2.3 (WANem
version 2.3) live compact disk (CD) for the simulation of latency, jitters and
packet loss in WAN as well as in LAN. All network traffic is routed through
this computer running WANem so that latency and jitters can be measured and
documented.
4.3.1.4 WANem [71]
WANem is distributed in the form of a bootable CD [71]. It was developed by
TATA Performance Engineering Research Centre, India [71]. It supports various
features such a bandwidth limitation, latency, packet loss, network disconnection
among other WAN characteristics. But in our study, we used WANem to simulate
Ethernet network packet delay and jitters when local cloud is used for real-time
65
industrial process control. The version used in this study is version 2.3 [72]. After
downloading the iso file of WANem version 2.3, the installation files are burnt to a
CD. Once the personal computer (PC) is booted with the WANem CD and the packets
between the end nodes are routed via WANem, then WANem is ready for use. Using
windows command prompt to create a static route from the Web server to the Arduino
through WANem system, all real-time control traffic are subjected to the preset
latency and jitters in WANem. The differences between the preset parameters and the
actual values monitored through windows command prompt are recorded as the real
latency, jitters and packet losses. These form our data for analysis. The procedure for
starting the WANem PC and getting packets routed via WANem is explained in detail
in the setup guide [73]. The procedure is also explained in Section 4.3 below. The
advanced configuration interface in WANem is shown in Figure 26 below.
Figure 26 WANem Advanced Configuration Interface.
66
4.3.2 The Profibus DP Simulation System
This simulation system used in this thesis study also comprises some hardware
and software, which enable the acquisition of data for the performance comparative
analysis.
Hardware
The following hardware were used in the study:
a. Dell Latitude E6230 Laptop
This is a 64-bits Personal Computer (Laptop) running on 64-bits Windows 7
Professional operating system. It also has an Intel Core i5 process with 2.9 GHz clock
speed. Its random access memory is 4 GB. This is the same computer used as a Web
server in the local cloud system simulation described in Section 4.2.1.1.2 above.
b. Profibus DP Gateway/slave made by BradCommunication
The model used for this study is Brad DRL-DPS-SRM Direct-Link
Gateway/Profibus-DP Slave module. The picture of the Profibus-DP gateway is
shown in Figure 27 below, while the general characteristics are specified in the
datasheet shown in Figure 28 below.
67
Figure 27 Brad DRL-DPS-SRM Direct-Link Gateway/Profibus-DP Slave Module With 24VDC Power Supply Adapter.
68
Figure 28 General Technical Specifications Brad DRL-DPS-SRM Direct-Link Gateway/Profibus-DP Slave Module [74].
This Profibus DP gateway is used in combination with RS232/RS485 Serial
converter to communicate over a serial bus to the Arduino Control system model.
c. RS232/RS485-to-Ethernet Converter
The c. RS232/RS485-to-Ethernet Converter module used in this study is USR-
TCP232-306 [75] model of USR IOT product. It has RS232 port, RS422/RS485
interface, and RJ45 Ethernet 10/100Mb port. The Ethernet port is connected to the
Arduino Mega 2560 Ethernet shield using Ethernet straight-through cable. The RS232
is connected to the RS232 port of Brad DRL-DPS-SRM Direct-Link
Gateway/Profibus-DP Slave to pass serial communication traffic to the Arduino
control system. The TCP/IP-to-RS232/RS485 converter is shown in Figure 29 below,
whereas the Serial RS232/RS485-to-TCP/IP is shown in Figure 30 below. The remote
server window is configured to have an IP address of the Arduino Mega Ethernet
shield.
69
Figure 29 TCP’IP-TO-RS232/RS485 Converter.
70
d. A Battery-Powered Oscilloscope (Tektronix THS3000 Series)
Figure 30 Tektronix Portable Oscilloscope (THS3000 Series).
A battery-operated Oscilloscope is used to prevent issues associated with
electrical noise. The following are the key performance specifications of the
Oscilloscope [77]:
• 100 MHz or 200 MHz bandwidth models
• Maximum sample rates up to 5 GS/s and 200 ps resolution
• Four fully isolated and floating channels
• 600 Vrms CAT III, 1000 Vrms CAT II rated inputs (Bayonet Neill–
Concelman [BNC] to earth ground).
The vertical and horizontal characteristics required for accurate measurement
in Profibus-DP network. They are presented as follows [77]:
71
Software for the Profibus-DP Simulation
The most important software for the Profibus-DP simulation is HMS Anybus
Profibus-DP Master Simulator, which is described as follows:
Profibus Master Simulator
Profibus Master Simulator consists of the software and the profibus universal
asynchronous receiver-transmitter (UART), which is a useful interface between
RS232 interface of a personal computer and a profibus slave. This is a user interface
software application used for configuring Profibus-DP master parameters to enable
interaction between the PC-based Profibus-DP Master simulator and the slave
connected in a Profibus network. The simulator processes GSD files from any
manufacturer of Profibus slave interface card. In this study, we used HMS Anybus
72
Profibus-DP Master Simulator [75] for monitoring real-time control traffic between
the Web server and the Arduino control system. It plays a similar role WANem plays
in the local cloud system as mentioned in Section 4.2.1.3 above. The configuration
interface of the Profibus Master Simulator is shown in Figure 31 below.
Figure 31 Configuration Interface of the Profibus Master Simulator.
4.4 Step-by-step Experiment Procedure
The experiments are of two aspects. The first one is to simulate and identify
issues of latency and jitters in using the local cloud system to perform real-time
control using Arduino control system model in a local area control network (LACN).
This involved the use of WANem as a network monitoring and network parameters
simulation application tool. The second one is to use the Profibus-DP Master
Simulator as our monitoring and network parameters simulator. Therefore, the
experiments procedures are subdivided into two for ease of data presentation and data
analysis. Six runs were determined for both experiments using no standards. In other
73
words, we did not use any criteria to arrive at performing six runs for both
experiments. It was just for the convenience of time available for the experiments due
to challenges of sourcing of material. The same values of latency was used for jitters,
which is a measure of variation of latency or delay in data transmission, just monitor
discrepancies in the delay pattern and also check for data loss as delay increases.
4.4.1 Local Cloud System Experiment in LACN
In this experiment, involving the use of local cloud and WANem setup, real
packets from a live application (Web server, from which real-time ON and OFF
command to the Arduino model control system is issued) are sent to the emulation
server. These real packets are modulated into a simulation packet; in turn, these
packets are demodulated into real packets. These packets have experienced the effects
of loss, delay, network jitters, etc., thereby transferring those network issues into the
real packet. It is as if the real packet had travelled through real networks, when in
reality it has only gone across a simulated network [75].
4.4.2 Method of Latency Measurement
The purpose of this section is to explain why we chose the PING utility as a
reliable method of latency measurement in this experiment. In any networked real-
time system, it is highly necessary for all devices and systems to have the same or
precise time (network time) in order to ensure high accuracy [76]. This is normally
achieved by synchronizing the time of all the networked devices. In which case, very
expensive hardware in the form of a Network Time Server is required. However,
inexpensive alternative to a distributed high-resolution hardware clock is to measure
latency using the reflector method called PING PONG or PINGING [76]. The
reflector test is the standard practice used in Low Latency Messaging performance
74
benchmarks [76]. It involves a sender transmitting message to the reflector, which
performs both receiving and transmitting functions at the same time. This is shown in
Figure 32 below.
Figure 32 Reflector Process known as the PING PONG (PINGING method).
The work done by IBM [76] helps us to arrive at the formula for calculating
latency for the symmetrical latency test (that is, 1 K messages/second from the sender
to the reflector and 1 K messages/second from the reflector to the receiver); the
following formula was used:
SH1K = RTT1K / 2, (1)
where X is the message rate in messages per seconds from the sender to the
reflector.
SH1K = Single Hop Latency
RTT1K = Round Trip Time
75
Having established the basis for the use of ping utility, the steps undertaken in
the experiments are now presented.
Step 1: In the first step, a network static route or host route was created to
route all network packets to the Arduino model Control system through the WANem
system. This was done by issuing the following command in the windows command
prompt:
route add {destination IP} mask 255.255.255.255 {WANem IP}
route add 192.168.1.111 mask 255.255.255.255 192.168.1.9,
where the IP address of the Arduino model control system 192.168.1.111 and
that of WANem system is 192.168.1.9.
Step 2: Latency, jitters and packet loss are configured in the WANem
advanced interface as shown in Figure 33 below. The latency and jitters are set in
multiples of 10 ms.
Figure 33 Advanced Configuration Interface of WANem.
76
Step 3: We then continuously pinged the IP address (192.168.1.111) of the
Arduino model Control system (192.168.1.111) from the web server and recorded the
outcome. The continuous ping command is issued in the windows command prompt
of the web server as follows:
Ping 192.168.1.111 –t
Step 4: Record the average response time of the ping command when no real-
time command is issued on the web page of the Arduino. Then, while the continuous
pinging is still on, we opened the web page of the Arduino through a web browser in
the Web server and issued an ON command. We observed if any change in the
response time of the ping reply occurred and recorded it. We later issued an OFF
command and observed and recorded the response time. The observation showed no
difference because the ping command represents the real-time command. Figures 34a
and 34b below show the web interface for issuing the ON an OFF command to the
Arduino model control system.
Figure 34a Arduino Model Control System Web interface for Real-Time Control When the ON Command is Issued.
77
Figure 34b Arduino Model Control System Web Interface for Real-Time Control When the OFF Command is Issued.
Step 5: The result is recorded and a summary table was created as shown in
Table 10 below. The details of the result are presented in Chapter 5 of this report.
4.4.3 Profibus-DP Model Control System Experiment
In this section, we provide the steps taken to simulate the control signal in a
Profibus-DP network.
Step 1: The female DB9 connector of a serial cable with alternate male DB9
connector is connected to the COM port of Dell Latitude E6230 laptop docking
station. The alternate male DB9 of the serial cable is connected to an RS232-to-
Profibus Converter. The converter is then connected to the RS232 port of the
BradCommunications DRL-DPS-SRM Direct-Link Gateway/Profibus-DP Slave
module.
78
Step 2: The RS232 output of the BradCommunications DRL-DPS-SRM
Direct-Link Gateway/Profibus-DP Slave module is then connected to RS232.RS485-
to-TCP converter. The switch on the Profibus-DP gateway is set to transmit through
EIA R485 serial communication.
Step 3: The RS232/RS485-to-TCP converter is connected to the Arduino
Mega 2560 model control system.
Step 4: The communication settings in the Profibus Master simulators are
configured. The COM port and the Master address are selected in the communication
configuration interface as shown in Figure 35 below.
Figure 35 Profibus Master Simulator Communication Settings Configuration Interface.
Step 5: The GSD file for the BradCommunications Profibus-DP gateway is
selected and the input and output parameters are selected. This is to define input
data/output data. This is shown in Figure 36 below.
79
Figure 36 Selection of the GSD File and the Input/Output Parameters.
Step 6: The battery-operated Oscilloscope (Tektronix THS3000 Series) is set
to time division on both channels A and B to measure Voltage over time to ensure the
round trip time is measured simulated data from the Profibus Master Simulator. The
time is adjusted to milliseconds, while the voltage is adjusted to millivolts.
Step 7: Delay is captured using a battery-operated Oscilloscope, whose serial
port is set to RS485 and connected to the output RS485 terminal of the
BradCommunications Profibus-DP gateway.
Step 8: Data is inputted through the Profibus Master Simulator as shown in
Figure 37 below. The response is measured via the Oscilloscope. The readings of the
time response are tabulated in Table 11 below.
80
Figure 37 Data Input Through Profibus Master Simulator.
Table 11 Response Time as Converted From Digital Oscilloscope.
Profibus-
DP
Latency
(ms)
0.0 0.05 0.1 0.15 0.2 0.25
81
CHAPTER 5. RESULTS AND ANALYSIS
5.1 Introduction
The results and analysis are presented in this chapter. The local cloud model
control system is first presented, followed by the Profibus-DP network delay tests.
5.2 Result of Local Cloud Model System Experiment
The experiment was conducted using the following six-pair latency and jitters
values as shown in Table 12 below. A note here is that jitter is defined in this context
as variation in delay.
Table 12 Result of the Local Cloud Model System Experiments.
Experiment Simulated
Latencies (ms)
Simulated Jitters (ms)
1 0 0
2 10 10
3 20 20
4 30 30
5 40 40
6 50 50
82
Experiment 1, Simulation 1:
Ping utility was used without connection to the WAN/LAN emulator system
(WANem system) to check for proper connectivity and delay and the Arduino Model
Control System output actual was switched ON and OFF. The ping result is shown in
Figure 38 below. Both simulated latency and jitters were zero.
Figure 38 Simulation 1 Experiment Ping Result. This is Without WAN/LAN Emulator (WANem).
Experiment 1, Simulation 2:
In simulation 2, the WAN/LAN emulator system (WANem) was connected
and a static route was created via the WANem system. The ping utility was used to
test for the latency. Figure 39 below shows the response from the ping utility. Both
the values of simulated latency and jitters were 10 ms.
83
Figure 39 Result of Ping Response in Experiment 1, Simulation 2.
The screenshot in Figure 39 shows that the average round trip time from the
ping utility when simulated latency and jitters were set at 10 ms is 32 ms. The latency
was calculated approximately when the average round trip time (RTTavg) is divided
by two [73]. Therefore, latency for Simulation 1 is
RTTavg/2 (2)
[73][76]
Therefore, Latency for Experiment 1 Simulation 2 = 32 ms/2 = 16 ms
Experiment 1, Simulation 3:
In this Simulation 3, Simulated Latency = 20 ms, Simulated Jitters = 20 ms.
Results are shown in Figure 40 below.
84
Figure 40 Result of Ping Response in Experiment 1, Simulation 3.
The result shows that the average round trip time was 45 ms, which means that
the latency was 45/2 = 22.5 ms.
Experiment 1, Simulation 4:
In this Simulation 4, the Simulated Latency = 30 ms, Simulated Jitters = 30
ms. Results are shown in Figure 41 below.
Figure 41 Result of Ping Response in Experiment 1, Simulation 4.
85
The result showed that the average round trip time was 72 ms; therefore, using
the following equation:
RTTavg/2, the latency was found to be 72 ms/2 = 36 ms
(3)
Experiment 1, Simulation 5:
In Simulation 5, Simulated Latency = 40 ms, Simulated Jitters = 40 ms.
Results are shown in Figure 42 below.
Figure 42 Result of Ping Response in Experiment 1, Simulation 5.
The average round trip time was 91 ms. Therefore, latency was 91/2 = 45.5
ms.
Experiment 1, Simulation 6:
Experiment when Simulated Latency = 50 ms, Simulated Jitters = 50 ms.
Results are shown in Figure 43 below.
86
Figure 43 Result of Ping Response in Experiment 1, Simulation 6.
The average round trip time, RTTavg = 161 ms. Therefore, latency was 161/2 =
80.5 ms.
87
5.3 Local Cloud Experiment Result Summary
Table 13 Summary of the Local Cloud Model System.
Data Transmission rate (Mbit/s)
Expected Response Time (ms)
Simulated Latency (ms)
Simulated Jitters (ms)
Average Round Trip Time (ms)
Link Latency (RTTavg/2)
(ms)
Jitters
Observed
(ms)
100 <1 0 0 0 0 0.0600197
100 <1 10 10 32 16 13.47654
100 <1 20 20 45 22.5 25.8442
100 <1 30 30 72 36 36.2994
100 <1 40 40 91 45.5 47.7988
100 <1 50 50 161 80.5 67.4744
The result summary in Table 13 above gives us the following summary of the
latency or delay in the local cloud model control system:
Latency (ms) 0.0 16 22.5 36 45.5 80.5
These latencies are used as sample variables for T-test analysis.
88
5.4 Profibus-DP Experiment Result Summary
The summary of the Profibus Simulation experiment has been provided in
Section 4.3.2. as:
Profibus-DP
Latency (ms)
0.0 0.05 0.1 0.15 0.2 0.25
5.5 Analysis
T-test is the procedure used for the analysis of results of the two simulations,
the local cloud model control system and the model Profibus-DP Network for
mimicking real-time control. The software application used for the T-test IBM-SPSS
has been developed by IBM. The results of the simulations have been tabulated in
Table 14 below.
89
Table 14 Results from the Two Simulations.
Time Local Cloud Latency
(ms)
Profibus-DP Latency
(ms)
Time 1 0 0
Time 2 16 0.05
Time 3 22.5 0.1
Time 4 36 0.15
Time 5 45.5 0.2
Time 6 80.5 0.25
This table was used for the analysis in IBM-SPSS software application.
5.5.1 T-Test Procedure
T-Test
T-TEST
/TESTVAL=0
/MISSING=ANALYSIS
/VARIABLES=LCLatency PDLatency
/CRITERIA=CI(.95).
* Chart Builder.
GGRAPH
/GRAPHDATASET NAME="graphdataset" VARIABLES=TIME MEAN
(LCLatency) MEAN(PDLatency)
MISSING=LISTWISE REPORTMISSING=NO
90
TRANSFORM=VARSTOCASES(SUMMARY="#SUMMARY"
INDEX="#INDEX")
/GRAPHSPEC SOURCE=INLINE.
BEGIN GPL
SOURCE: s=userSource(id("graphdataset"))
DATA: TIME=col(source(s), name("TIME"), unit.category())
DATA: SUMMARY=col(source(s), name("#SUMMARY"))
DATA: INDEX=col(source(s), name("#INDEX"), unit.category())
GUIDE: axis(dim(1), label("Time"))
GUIDE: axis(dim(2), label("Mean"))
GUIDE: legend(aesthetic(aesthetic.color.interior), label(""))
SCALE: cat(dim(1), sort.natural())
SCALE: linear(dim(2), include(0))
SCALE: cat(aesthetic(aesthetic.color.interior), include("0", "1"))
ELEMENT: line(position(TIME*SUMMARY), color.interior(INDEX),
missing.wings())
END GPL.
91
N Mean Std. Deviation
Std. Error Mean
Local Cloud Latency
6 33.4167 27.95964 11.41448
Profibus-DP Latency
6 .1250 .09354 .03819
One-Sample Test
Test Value = 0
T df Sig. (2-tailed)
Mean Difference
95% Confidence Interval of the
Difference
Lower Upper
Local Cloud Latency
2.928 5 .033 33.41667 4.0748 62.7585
Profibus-DP Latency
3.273 5 .022 .12500 .0268 .2232
92
Graph
TimeLocal Cloud Latency
Profibus-DP Latency
Time 1 0 0Time 2 16 0.05Time 3 22.5 0.1Time 4 36 0.15Time 5 45.5 0.2Time 6 80.5 0.25
0
10
20
30
40
50
60
70
80
90
0 1 2 3 4 5 6 7
Chart Title
Local Cloud Latency Profibus-DP Latency
93
5.5.2 Result of Analysis
The result of the analysis clearly shows that Profibus-DP is more reliable for
real-time control than local cloud system because it responds faster. And it has less
network challenge when compared with that in IP-based systems.
5.5.3 Recommendations
This study is geared toward recommending further studies that would create
opportunity for building industrial network systems, which would provide a
combination of the following capabilities:
Real-time control with minimal latencies and jitters as being experienced in
cloud system
Fast data computing and processing
Remote site accessibility with speed and reliability
Very high storage
Heterogeneous, non-proprietory and highly interoperable in nature.
94
REFERENCES
[1] Jim Pinto; Industrial Automation and the Cloud: https://www.
automationworld.com/article/topics/cloud-computing/industrial-automation-
and-cloud
[2] Ms. Latha D S, Deputy General manager and Mr. K. Jayaprakash, General
Manager – Instrumentation and controls, Tata Consulting Engineers; Article:
The Rise of Cloud Computing in Industrial Process – https://
www.automation.com/automation-news/article/the-rise-of-cloud-computing-
in-industrial-process-automationAutomation
[3] Wikipedia: https://en.wikipedia.org/wiki/Fog_computing
[4] Professor Jerker Delsing, LuLea University of Technology, Sweden:
Automation Systems from IoT Arrowhead Framework: concepts and basic
architecture. www.arrowhead.eu
[5] Prof. Dr.-Ing. Reinhard Langmann, FH Düsseldorf, Competence Center
Automation Düsseldorf (CCAD); An article published on Industrial Ethernet
Book website: http://www.iebmedia.com/?id=9254&parentid=74&themeid=
255&showdetail=true&bb=true
[6] VDI/VDE-Gesellschaft Mess und Automatisierungstechnik (GMA). Cyber-
physical systems: Chancen und nutzen aus sicht der automation. Thesen und
Handlungsfelder, April 2013.
[7] Jerker Delsing; IoT Automation – Arrowhead Framework, 2017.
95
[8] Sunit Kumar Sen; Fieldbus and Networking in Process Automation, CRC
Press, 2014.
[9] Technical Information by Yokogawa: TI 38K03A01-01E, 2002.
[10] IEC61158 Technology Comparison – State of the Bus; Fieldbus Inc.
[11] Wikipedia: https://en.wikipedia.org/wiki/Fieldbus
[12] Fieldbus Comparison: http://www.er-soft.com/files/media/files/ER-Soft--
Fieldbus--Comparison--Chart.pdf
[13] Profibus: https://en.wikipedia.org/wiki/Profibus
[14] Profibus International: PROFIBUS System Description Technology and
Application.
[15] Smar – Profibus Protocol: http://www.smar.com/en/profibus
[16] http://profibus.felser.ch/en/index.html?synchrone_-_mbp_installation.htm
[17] Song, S. Han, A. K. Mok, D. Chen, M. Lucas, M. Nixon, and W. Pratt.
Wirelesshart: Applying wireless technology in real-time industrial process
control. IEEE Real-Time and Embedded Technology and applications
Symposium, 2008. St. Louis, USA.
[18] R. Langmann and L. Meyer, “Automation services from the cloud,” in 11th
IEEE International Conference on Remote Engineering and Virtual
Instrumentation (REV), 2014, pp. 256–261.
[19] Richard Zurawski; Industrial Communication Technology, Second Edition,
CRC Press, 2015.
96
[20] http://www.guru99.com/cloud-computing-for-beginners.html
[21] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computing and its role in
the internet of things,” in Proceedings of the 1st edition of the MCC workshop
on Mobile cloud computing, pp. 13–16, ACM, 2012.
[22] How fog computing pushes IoT intelligence to the edge – https://
techcrunch.com/2016/08/02/how-fog-computing-pushes-iot-intelligence-to-
the-edge/
[23] Fog Computing in an Industrial Context – http://www.controldesign.com/
articles/2017/fog-computing-in-an-industrial-context/
[24] L. M. Vaquero and L. Rodero-Merino, “Finding your Way in the Fog:
Towards a Comprehensive Definition of Fog Computing,” SIGCOMM
Computer Communication Review, vol. 44, no. 5, pp. 27–32, 2014.
[25] Alma Didic and Pavlos Nikolaidis: Real-time Control in Industrial Internet of
Things (IoT), Malardalen University, School of Innovation Design and
Engineering, Vasteras, Sweden, 2015.
[26] National Institute of Standards and Technology (NIST): https://www.nist.
gov/news-events/news/2011/10/final-version-nist-cloud-computing-definition
-published
[27] Cloud Computing Tutorial by tutorialspoint.com
[28] Peter Mell and Tim Grance; Formal definition of cloud computing by NIST.
97
[29] Bill Lydon, Intech Editor-in-Chief; Article: How Cloud Computing Delivers a
New Industrial Automation Tool for Improving Operations, Intech Magazine,
June, 2015.
[30] V. A. Kumar and E. Prasad, “Fog Computing: Characteristics, Advantages
and Security Privacy,” International Journal of Computer Science and
Management Research, vol. 3, no. 11, 2014.
[31] Stojmenovic, “Fog computing: A cloud to the ground support for smart things
and machine-to-machine networks,” in Australasian Telecommunication
Networks and Applications Conference (ATNAC), pp. 117–122, 2014.
[32] M. Yannuzzi, R. Milito, R. Serral-Gracia, D. Montero, and M. Nemirovsky,
“Key ingredients in an IoT recipe: Fog Computing, Cloud computing, and
more Fog Computing,” in 19th IEEE International Workshop on Computer
Aided Modeling and Design of Communication Links and Networks
(CAMAD), pp. 325–329, 2014.
[33] National Institute of Standard and Technology (NIST) Cloud Computing
reference architecture (SP 500-292), 2011.
[34] National Institute of Standard and Technology (NIST) Cloud Computing
definition publication (800-145), 2011.
[35] Torry Harris; Cloud Computing Overview: http://www.thbs.com/thbs-
insights/cloud-computing-overview
[36] Nisha Peter, “FOG Computing and Its Real Time Applications”, published in
International Journal of Emerging Technology and Advanced Engineering:
98
www.ijetae.com (ISSN 2250-2459, ISO 9001:2008 Certified Journal, Volume
5, Issue 6, June 2015).
[37] Shabnam Kumari1, Surender Singh and Radha; “Fog Computing:
Characteristics and Challenges”, published in International Journal of
Emerging Technology and Advanced Engineering: www.ijettcs.org Email:
[email protected] Volume 6, Issue 2, March–April 2017.
[38] Flavio Bonomi, Rodolfo Milito, Jiang Zhu, and Sateesh Addepalli, “Fog
Computing and Its Role in the Internet of Things”, Cisco System Inc.
[39] F. Bonomi, R. Milito, P. Natarajan, and J. Zhu, “Fog computing: A platform
for Internet of Things and analytics,” in Big Data and Internet of Things: A
Roadmap for Smart Environments (Studies in Computational Intelligence).
New York, NY, USA: Springer, 2014, pp. 169–186.
[40] NIKHIL SABU; FOG COMPUTING TECHNOLOGY: https://www.
slideshare.net/NikhilSabu/fog-computing-technology
[41] Charles C. Byers and Patrick Wetterwald: Fog Computing: Distributing data
and intelligence for resiliency and scale necessary for IoT.
[42] Eva Marín Tordera*, Xavi Masip-Bruin, Jordi García-Almiñana, Admela
Jukan Guang-Jie Ren, Jiafeng Zhu , Josep Farré†: What is a Fog Node? A
Tutorial on Current Concepts towards a Common Definition.
[43] https://www.rtinsights.com/what-is-fog-computing-open-consortium/
99
[44] R. Langmann and L. Meyer, “Automation services from the cloud,” in 11th
IEEE International Conference on Remote Engineering and Virtual
Instrumentation (REV), 2014, pp. 256–261.
[45] H. Sequeira, P. J. Carreira, T. Goldschmidt, and P. Vorst, “Energy Cloud:
real-time cloud-native Energy Management System to monitor and analyze
energy consumption in multiple industrial sites,” in 7th IEEE/ACM
International Conference on Utility and Cloud Computing (UCC), 2014.
[46] O. Givehchi, H. Trsek, and J. Jasperneite, “Cloud computing for industrial
automation systems – A comprehensive overview,” in 18th IEEE Conference
on Emerging Technologies & Factory Automation (ETFA), 2013, pp. 1–4.
[47] O. Givehchi, J. Imtiaz, H. Trsek, and J. Jasperneite, “Control-as-a-service
from the cloud: A case study for using virtualized PLCs,” in 10th IEEE
Workshop on Factory Communication Systems, 2014.
[48] W. Zhang, M. S. Branicky, and S. M. Phillips, “Stability of networked control
systems,” Control Systems, IEEE, vol. 21, no. 1, pp. 84–99, 2001.
[49] J. P. Hespanha, P. Naghshtabrizi, and Y. Xu, “A survey of recent results in
networked control systems,” Proceesings of the IEEE, vol. 95, no. 1, 2007.
[50] T. C. Yang, “Networked control system: a brief survey,” IEE Proceedings-
Control Theory and Applications, vol. 153, no. 4, 2006.
[51] T. Hegazy and M. Hefeeda, “Industrial automation as a cloud service,” IEEE
Transactions on Parallel and Distributed Systems, vol. PP, no. 99, pp. 1–1,
2015.
100
[52] CISCO; Fog Computing and the Internet of Things: Extend the Cloud to
Where the Things Are: http://www.cisco.com/c/dam/en_us/solutions/trends/
iot/docs/computing-overview.pdf
[53] ISA, “International standard for the integration of enterprise and control
systems.” http://www.isa-95.com/ [Online; Accessed 20-May-2015].
[54] D. S. Hira; System Simulation, Second Edition, 2008.
[55] Arrowhead Technical Architecture: https://forge.soa4d.org/plugins/media
wiki/wiki/arrowhead-f/index.php?title=Technical_architecture&printable=yes
[56] Csaba Heged. Us, Daniel Kozma, Gabor Soos and Pal Varga; Enhancements
of the Arrowhead Framework to Refine Inter-cloud Service Interactions.
[57] Jerker Delsing, Jens Eliasson, Jan van Deventer, Hasan Derhamy, Pal Varga;
Enabling IoT automation using local clouds.
[58] Wikipedia: https://en.wikipedia.org/wiki/Systems_architecture
[59] Simulation and Model Team; http://www.uh.edu/~lcr3600/simulation/
contents.html
[60] https://www.anybus.com/products/gateway-index/specific-gateways/master-
simulators/detail/profibus-master-simulator
[61] http://www.dell.com/en-us/work/shop/cty/pdp/spd/latitude-e6230
[62] https://en.wikipedia.org/wiki/List_of_Intel_Core_i5_microprocessors
[63] https://ark.intel.com/products/71256/Intel-Core-i5-3380M-Processor-3M-
Cache-up-to-3_60-GHz
101
[64] http://www.usr.so/product-category/serial-to-ethernet/rs232-rs485-rs422-to-
ethernet-converter/?gclid=CjwKCAjw6szOBRAFEiwAwzixBRQXZyLX6
pyhZugtbTW8PF4SyxeUDXnC2lHaPkZBDYt75qbSjMSGSRoC6aQQAvD_
BwE
[65] https://www.arduino.cc/en/Main/Software
[66] https://github.com/MichaelJonker/HardwareSerialRS485
[67] https://download.mikroe.com/documents/compilers/mikroc/pic/help/onewire_
library.htm
[68] Michael Jonker; https://github.com/MichaelJonker/HardwareSerialRS485/
wiki
[69] Rui Santos and Sara Santos Random Nerd Tutorials: Arduino Step-by-step
Projects Build 25 projects! Version 2.0
[70] https://www.embarcados.com.br/arduino-rs-232-rs-485-hardware/
[71] http://wanem.sourceforge.net/documentation.html
[72] http://wanem-wide-area-network-emulator.soft112.com/
[73] WANem 1.1 Wide Area Network Emulator User Guide; Performance
Engineering Research Centre, April 27, 2007.
[74] http://www.molex.com/molex/products/datasheet.jsp?part=active/1120260013
_NETWORK_INTERFACE.xml&channel=Products&Lang=en-US
[75] http://www.m2optics.com/blog/wanem-delay-simulator
102
[76] IBM; Measuring Latency – https://www.ibm.com/support/knowledgecenter/
en/SSQPD3_2.6.0/com.ibm.wllm.doc/measuringlatency.html
[77] https://www.tek.com/datasheet/ths3000-series-handheld-oscilloscopes-data
sheet
[78] Ben Dickson; How fog computing pushes IoT intelligence to the edge.
[79] Omid Givehchi, Henning Trsek, and Juergen Jasperneite; Cloud Computing
for Industrial Automation Systems – A Comprehensive Overview; IEEE
Publication, 2013.
[80] B. Vogel-Heuser, G. Kegel, K. Bender, and K. Wucherer. Global information
architecture for industrial automation. Automatisierungstechnische Praxis
(atp), Oldenbourg-Verlag, Muenchen, 2009.
[81] Omid Givehchi, Jurgen Jasperneite; Industrial Automation Services as part of
the Cloud: First Experiences, 2015.
[82] Jochen Schlick, Peter Stephan, and Thomas Greiner. Kontext, Dienste und
Cloud Computing – Eigenschaften und Anwendungen cyber-physischer
Systeme. atp edition, 04, 2013.
[83] TAO Jun, WANG Zhan-lin, Analysis of PROFIBUS.DP Network Delay and
Its Influence on the Performance of Control Systems, 2005.
103
