Common protocol to support disparate communication types within industrial Ethernet environments

University of Missouri-St. Louis
From the SelectedWorks of Maurice Dawson
2016
Common protocol to support disparate
communication types within industrial Ethernet
environments
Jacqueline MacPherson
Maurice Dawson
Available at: http://works.bepress.com/maurice_dawson/39/

134 Int. J. Network Science, Vol. 1, No. 2, 2016
Copyright © 2016 Inderscience Enterprises Ltd.
Common protocol to support disparate
communication types within industrial Ethernet
environments
Jacqueline MacPherson
Department of Computer Science,
College of Engineering and Computer Science,
Colorado Technical University,
4435 N. Chestnut St., Colorado Springs, CO 80907, USA
Email: jacqueline.macpherson@us.festo.com
Maurice Dawson*
Department of Information Systems,
College of Business Administration,
University of Missouri-St. Louis,
228 ESH, One University Blvd, St. Louis, MO, USA
Email: Maurice.e.dawson@gmail.com
*Corresponding author
Abstract: Owing to the increasing demand for reliable products built globally,
and through the evolution of machine design, the need for improved and a
common communications protocol in different geographical regions has
intensified. In this paper, the goal is to reveal that the current protocols used to
support disparate communication types in manufacturing have caused
complexity in configurations and an increase in monetary overhead for
industrial system designers and the end users. Through the simulation of an
industrial network, the packet timing, and packet loss between peer-to-peer
systems, similar protocol systems will be compared with two dissimilar
protocols systems to establish the thesis. The internal validation research
method used in this study will reveal the need for an all-inclusive protocol to
eliminate the timing and packet loss issues, the systems’ configuration
complexities, and the need to reduce the monetary overhead currently
associated with the machine communications.
Keywords: common protocol; industrial system designers; packet timing;
peer-to-peer systems.
Reference to this paper should be made as follows: MacPherson, J. and
Dawson, M. (2016) ‘Common protocol to support disparate communication
types within industrial Ethernet environments’, Int. J. Network Science, Vol. 1,
No. 2, pp.134–154.
Biographical notes: Jacqueline MacPherson is currently a Training Program
Manager at the Festo. Previously, she was the Industry Segment Manager for
Printing, Paper, and Converting, and Engineer IV, Fluent Power Engineering
Leader. She is a member of the National Association of Professional Women
(NAPW), and local groups regarding industrial automation. Her research
interests include industrial ethernet, system automation, and power engineering.

Common protocol to support disparate communication types 135
Maurice Dawson is an Assistant Professor of Information Systems (Cyber
Security) at the University of Missouri – St. Louis (UMSL). Additionally, he
was a Visiting Assistant Professor (Honorary) at the University of Tennessee
Space Institute in the College of Engineering within the Department of
Industrial and Systems Engineering. He received two Fulbright Scholar
Specialist Grants to go to Russia in 2014 [Project #5824/South Ural State
University] to lecture on business intelligence (BI) and Bangladesh in 2016
[Project #6296/University of Rajshahi] to lecture on cyber security. He served
as a Visiting Scholar with the University of the Gambia in 2013 and through
the International Studies and Programs (ISP) Fellowship awarded from UMSL
in 2014.
1 Introduction
Organisations require the utmost flexible and scalable capabilities in order to quickly
respond to the rapidly changing global marketplace. In a statement made by Frost and
Sullivan, an industry market analysis company, there are indications of a shift in the
global market. This shift has increased demand for faster time to market, which is causing
an evolution in manufacturing machine designs for reliable production (Zanchi, 2012).
Manufacturing is an industry with complex operations, where the success of any
organisation lies in producing the right products, at the right time, with higher quality,
and lower costs than the competition (Ismail and Paquin, 2012). Industrial networking
plays an important role in enabling real-time access to data in a manufacturing
plant floor. For manufacturers to be profitable, the need to consolidate their
disparate networks is a high requirement. Many different systems operating in a
production line require continuous communications with no or the least amount of
network downtime to share information. Network architecture facilitates the
communication of manufacturing systems and the latest architectures incorporate the use
of Ethernet.
At the present time, the current protocol standards are not addressing the needs of all
communication types within industrial Ethernet environments (Woods, 2011). One
example of this fact is the statement made by Woods in that the common industrial
protocol (CIP) does not perform well when many control axes are communicating at the
same time (Woods, 2011).
The CIP that Woods (2011) referred to is shown in layers five through seven. Each
protocol used within an industrial network can be associated with different layer locations
in the open systems interconnection (OSI) model. Each layer of the OSI model handles
the packets being transmitted in different ways such as transmission control protocol
(TCP) does error checking but user datagram protocol (UDP) does not do any error
checking. Within an industrial network there are three types of traffic; real-time, hard
real-time, and non-hard real-time. Hard real-time traffic cannot tolerate latency (Löser
and Hártig, 2004). The speeds needed for hard real-time traffic can be as low as
10 milliseconds (ms) therefore delays can cause communications issues (Zhang et al.,
2008).

136 J. MacPherson and M. Dawson
This research is concerned with the issues of disparate communications within
industrial networks. Manufacturers today are dealing with legacy field bus networks and
Ethernet-based networks. The issue manufacturers’ face is these two network types
cannot be integrated to work harmoniously as one network (Carvajal and Fischmeister,
2013). This prevents the reduction of overhead costs such as resources, loss of production
due to downtime, and machine intelligence in order to increase output production. This
dissertation reveals the need for the application of a common protocol to support
disparate communication types within industrial Ethernet environments.
2 Motivation
Survival in the global business environment necessitates the implementation of scalable,
flexible, and cost-effective strategies and technology. Owing to the increasing demand
for reliable products built globally, the need for improved and speedy product lines
through the use of a common protocol of communications has increased per the Aberdeen
study. The industry is moving away from mechanical-based solutions to more
technologically advanced controls done through automation control platforms, such as
electric servo drives (Vaclav, 2006).
The communication structure of an automation control platform is formally known
within the manufacturing industry as the industrial network (Decotignie, 2009). The
automation control platforms include human to machine interface (HMI). These are
usually touch screens. The HMI will have a graphical user interface (GUI), which will be
used by the operators of the machine. The GUI will have written, along with pictorial,
instructions for the operation of the machine. Electronic photo eye sensors to sense the
movement can monitor the machine movements. The feedback from the photo eye
sensors is used to time the movement of an electronically driven motor. These motors are
usually servo-driven owing to high accuracy in rotation. The synchronisation of all of
these products is done through the use of industrial protocols on a network. This network
is what initiates the machine processes and begins the production of the consumer
product made by that machine.
The manufacturers of the machines that make the consumer product are known as
original equipment manufacturer (OEM) builders. Many studies, such as those of Felser
and Sauter (2002), Moyne and Tilbury (2007), and Arc Advisory Group white papers
have concluded that one of the most challenging tasks in industrial networks field is lack
of common communication protocols because this has not been addressed in industry.
Most OEM builders are experiencing difficulties with hardware, software, and
communication errors when designing the automation control platform for a machine.
Each of these areas of concern has considerations associated with them as it relates to
choice of product, integration between vendors, cost of the product, and ease of use for
both the design engineer and the end user.
The optimum choice for the simulation should be a protocol which resides between
layers three through seven and be associated with more than three communication
attributes. The reason for choosing these two requirements is to eliminate those protocols
which contain proprietary manipulation. This manipulation is the reason integration is not
possible between protocols and the basis for this research (ABB, 2012). Therefore,
Modbus – IDA and Profinet CbA have been discarded as they do not meet the OSI layer
requirements.

2.1 Significance of study
Industrial networks require reliable communication systems without any interruption to
handle machine control functions in house locally connected, and globally connected
through the Internet. The communication problems between systems create overhead
costs and are a result of using multiple protocols for communication. Managing networks
with various protocols is challenging. To reduce the cost and other overheads in the
industrial setting, the communication between disparate networked systems needs to be
seamless. This research reveals the need for a common standard protocol to facilitate the
communication between systems within industrial Ethernet environments. The research
done by Carvajal and Fischmeister (2013) also supports the need for a standard protocol
within the industry.
2.2 Problem statement
In a dynamic and inter-organisational setting, the common communication protocols
become key challenges. The lack of standardised common protocol for communication
types which causes loss of network packet deliveries, and latency within industrial
Ethernet environments translates to loss of revenue for manufacturing companies. The
goal behind applying a common protocol to support disparate communication types is to
investigate if it will provide the relevant data OEM builders and manufacturing
companies would need to reduce overhead and streamline the communication process.
2.3 Research questions
As this research will build a foundation for the need to create a standardised common
protocol for industrial Ethernet environments, the following questions will be answered:
• Research question 1: What are the benefits and drawbacks of applying standardised
common protocols to support communication types in the industrial Ethernet
environments?
• Research question 2: What is the ratio of packet loss with the same protocol vs.
packet loss using different protocol?
• Research question 3: What is the total processing time in an environment with the
same protocol vs. different protocol?
3 Research methodology
3.1 Design implementation
This section outlines a simulation of industrial Ethernet networks with protocols currently
used to reveal an outline of what could be a future common protocol. Owing to the
limited availability of a real-world industrial Ethernet network to perform this
experiment, a simulation was used in this study. We will discuss the setup and design of
the simulations and the structured approaches that will assist in this study. A simulated
industrial Ethernet network with switches and nodes were created, and a full-scale

detailed simulation analysis of switched industrial Ethernet networks will be performed.
The focus will be toward the communication scenario experiments to show the benefit of
a common protocol in an industrial Ethernet networks, and are outline in this chapter as
well. This study is using a theoretical model to build the foundation for the use of a
common protocol in industrial Ethernet networks communication. The theories and
models used were the simulated industrial Ethernet network, the inter-rater reliability
coefficient analysis or Cohen’s Kappa coefficient and statistical software SPSS.
3.2 Theories, models, and industrial Ethernet simulation
The simulation model will contain a 10/100BASE-TX network with the following
parameters. The transmission capacity is 100 MBits/sec, the delay between any two
stations is 30/ms, and the distance between stations will be set to 2.5 metres. The unit
time will be set to 512 bit times because this is a unit time for a typical industrial setup in
most manufacturing environments. For this simulation, the number of stations will be
kept at two, due to the availability of stations for testing. Also, different packet size
communication will be directed between the stations, some fixed packets and others
variable so the simulation can mimic a real world network setting.
In the simulation model, a 10/100 Mbps Ethernet switch will be used along with
interface between stations Syslink IEEE488, 24 pin. A 100 BASE-T network card and
100 BASE-T Fast Ethernet switch will be included to set the simulation model for this
research. The simulation will run for several seconds with different traffic loads. This
simulation will be used to create an event-based simulated environment for an Ethernet
network to assert that manufacturing companies could utilise benefits from the
application of common protocol and standards.
Cohen’s Kappa coefficient was used to quantify agreement between raters of a
nominal and continuous scale data to validate the perceived usefulness of a single
common protocol in industrial Ethernet environment. The goal is to show the reliability
and usefulness of the proposed method with the use of Kappa coefficient statistical
measurement of agreement. Kappa coefficient is a statistical measure of inter-rater
agreement, and the range is between 0 to 1 as follows, and a value-approximating zero is
interpreted as close to chance agreement. A value of Kappa close to 1 shows that a
common protocol for industrial Ethernet networks is a viable solution.
Kappa is interpreted as the proportion of agreement among raters after chance
agreement has been removed from the dataset. Measurements of agreement are from the
agreement of observed values with predicted values. Chance agreement increases as the
variability of observed ratings decreases. The statistical software package called SPSS
was used to analyse the data.
3.3 Research approach, procedures
An internal validity methodology will be used to build the simulation model based on
available data from industrial Ethernet networks used in manufacturing, and a
quantitative study will be applied to evaluate the benefit of applying a common protocol
in industrial Ethernet networks. During the initial phase of the simulation study, the
problem is defined. The target system is a simulated industrial Ethernet network setting.
The controlled environment of the simulation will facilitate the study of the dynamics of
an industrial Ethernet networks, and its configuration would allow the building of many

different scenarios to experiment with having different network protocols in a setting.
These protocols will follow the outline structure of the A, B, C model explained in
chapter one and two. In this dissertation research, the data collected from the existing
industrial Ethernet networks will form the foundation for the creation of the simulated
environment. The testing will reveal if the hypothesis of this research will stand, which is
having common protocol architecture could support disparate communication types in the
industrial Ethernet environments without any direct impact on machine communication
and availability of the network.
Cohen’s Kappa (often simply called Kappa) can be used as a measure of agreement
between the two raters to validate a process, testing, or data. Landis and Koch (1977)
proposed a benchmarking scale known as ‘Landis and Koch-Kappa’s benchmark scale’.
As shown in Table 1, the extent of agreement can be qualified as ‘poor’, ‘slight’, ‘fair’,
‘moderate’, ‘substantial’, and ‘almost perfect’ depending on the magnitude of Kappa.
Landis and Koch have characterised different ranges of values for Kappa with respect to
the degree of agreement they suggest. Kappa is used with multiple ratings per subject test
in which ratings can be performed by the same set of raters or by different raters. A
Kappa ranges of values (40%–60%), (60%–80%), and (80%–100%) indicate a moderate
agreement level, substantial and almost perfect agreement levels respectively.
Table 1 Landis and Koch-Kappa’s benchmark scale
Kappa statistic Strength of agreement
< 0.0 Poor
0.0 to 0.20 Slight
0.21 to 0.40 Fair
0.41 to 0.86 Moderate
0.61 to 0.80 Substantial
0.81 to 1.00 Almost perfect
The Landis and Koch Kappa value of above 0.40 for the support of a common industrial
Ethernet network is used in this research. Values greater than 0.75 or so may be taken to
represent substantial agreement beyond chance, values below 0.40 or so may be taken to
represent fair agreement beyond chance, and values between 0.40 and 0.75 may be taken
to represent moderate agreement beyond chance. The purpose during testing is to show
the data collected has been validated. The industrial Ethernet networks communication
yields to an inter-rater reliability coefficient measure, which is the percentage of observed
agreement within the total amount of agreement. Higher Kappa the better agreement
supports the usefulness of a common protocol for industrial Ethernet networks
communication.
The number of subjects (n), raters (r), and categories (q) affect the agreement
coefficient’s distribution. We study how the quantities n, r, and q affect the 75th
percentile (substantial agreement in the Landis and Koch-Kappa’s benchmark scale table)
of an agreement coefficient. The 75th percentile is a threshold that an agreement
coefficient can exceed only with a small chance below 25%. Kappa is expressed by the
following equation: Kappa = (Proportion of observed agreement – chance agreement) /
(1 – chance agreement), where P denotes the observed percentage of agreement, and P(e)
denotes the probability of expected agreement due to chance. Three data-collection
conditions should be met:

1 the subjects to be rated are independent of each other
2 the raters score the subjects in an independent fashion
3 the rating categories are mutually exclusive and exhaustive (Haley and Osberg,
1989).
Table 2 presents the methodology, data source, and statistical methods that will be
applied to answer the research questions.
Table 2 Methodology planning table
Research question Methodology Data source Statistical analysis
1 What are the benefits and
drawbacks of applying
standardised common protocol
to support communication types
in the industrial Ethernet
environments?
Quantitative Timing and
packet loss
Kappa
2 What is the ratio of packet loss
with the same protocol vs.
packet loss using different
protocol?
Quantitative Ratio of packet
loss
Two-sample T-test
analysis
3 What is the total processing
time in an environment with the
same protocol vs. different
protocol?
Quantitative Processing
time of two
independent
systems
One-variances test,
and one-sample
T-test
In order to reveal the benefit of applying standardised common protocol to support
communication types in the industrial Ethernet environment, internal validity research
method will be applied. In this method, the two variables utilised are time and packet
loss. The cause and effect of timing to packet loss has been noted in chapter two, showing
that timing delays cause packet loss. Timing can be associated with the protocol type as
will be seen in the simulation between protocol comparison of types A, B, and C.
Through the analysis, the correlation between these two variables (timing and packet
loss) should again show that packet loss is associated to timing. It will also show why it is
important to have a common communication protocol type between all devices on an
industrial network to reduce complexity of network structure, to increase network
availability, and reduce overhead.
A critical issue in developing the research methodology pertains to understanding the
concept of variables. Common variable types such as dependent, independent,
categorical, extraneous, and intervening variables are identified in the research.
Qualitative variables are projected to include regulatory compliance and policies.
Quantitative variables are projected to include the following: communication and
network setup, data-communication types, hardware and software, and quantity and time
span of resource availability.
Each simulation will be executed for a minimum of 180 seconds to allow at least
1,200 packets to be transmitted; some may not arrive at the destination due to packet loss.
The simulation for each scenario with different configuration protocol is run and the
results will be averaged over the multiple runs. Packet size of 512 bytes is used for fixed
packet size which is standard for transmission within an industrial network. For the

statistical analysis to answer the research questions, there were three run times done with
the test units which were three, six and nine minute times. From those times, 30% of the
data was selected for samples at random from these different testing scenarios. This
method is needed to compare the variation of the two different protocols using
one-variance test and to compare the mean processing time for two different protocols
using a one-sample t-test.
3.4 The architecture of simulated industrial Ethernet networks
In this research, two simulation test stations interconnected. For the first test, each
simulation test station utilised the Profinet RT protocol to capture the data transmission
looking at time to packet loss. For the second test, each simulation test station had
dissimilar protocols, one with Profinet RT and the next with Powerlink. At this point,
there will be a gateway used to do the protocol translation. The timing and packet
information must be extracted from the PLC as common packet evaluation software does
not capture the errors within the industrial network setup for this simulation.
3.5 The data collection techniques and analyses
Data was collected from the simulated environment to determine the feasibility of an
industrial Ethernet networks with a common protocol and disparate protocols. To address
the technical feasibility of applying a common protocol, the simulated environment
modelled after existing industrial Ethernet networks used in a manufacturing. The metric
used to analyse the performance of common protocol in these scenarios will be packet
delivery ratio. The data from the Kappa matrix was used by SPSS statistical software to
analyse collected data.
4 Results
The main objective of using a simulated industrial Ethernet network with switches and
nodes was to show the benefit of a common protocol in an industrial Ethernet networks.
This section presents the results achieved from the different simulation scenarios. The
metrics used to analyse the testing were packet delivery ratio, end-to-end latency, and
control overhead. For each cause of packet loss, the effect of packet loss on the
performance of the testing station was measured.
The configuration of a 10/100BASE-TX network for the testing included the
following parameters. The transmission capacity was 100 MBits/sec, the delay between
any two stations was 30/ms, and the distance between stations was set to 2.5 metre. The
unit time was set to 512 bit times because this is a unit time for a typical industrial setup
in most manufacturing environments. The number of stations was two, due to the
availability of stations for testing. Also, different packet size communication was directed
between the stations, some fixed packets and others variable to simulate a real-world
network setting. In the simulation model, a 10/100 Mbps Ethernet switch was used along
with interface between stations Syslink IEEE488, 24 pin. A 100 BASE-T network card
and 100 BASE-T Fast Ethernet switch were included.

Each simulation was executed for 154 seconds minimum to transmit at least
400 packets. Packet size of 512 bytes was used for fixed packet. The data transmission
rate varied between 400 packets per second and 4,000 packets per second to investigate
the effect of traffic load. For the statistical analysis to answer the research questions, the
random data samples from two different testing scenarios were selected to compare the
variation of the two different protocols using variances test and to compare the mean
processing time for two different protocols using a one-sample t-test.
The packet delivery ratio was examined with the first set of experiments to evaluate
the fraction of successful packet delivery in different traffic loads. The packet delivery
ratio is defined as the total number of data packets received at the destination divided by
the number of data packets transmitted from the source. The results are shown in
Figure 1. The normal transmission testing situation for this research was set to data
transmission rate of 400 packets minimum per second with a maximum 4,000 packets per
second and no pause time in between. This setting was achieved through the PLC error
checking procedure. This error table is where the data was extracted from. Non-normal
transmission testing situation varied in their parameters’ values.
Since only two stations with a close distance were used in this research, the network
size is considerably smaller than a normal network in the industry. However, the
maintaining of routes in this smaller network mirrored a large network with many nodes.
The network size did not have any impact on the packet delivery ratio in terms of
topology size. The time interval used was: three, six, and nine minutes during multiple
simulations runs. Figure 2 is the six-minute time interval shown as an example.
Figure 1 Packet delivery ratios in 6 minutes runtime (see online version for colours)

Figure 2 Packet losses in 6 minutes runtime (see online version for colours)
Table 5 was created to perform validation of the packet delivery testing. The table was
formed during the testing for the Kappa coefficient analysis. The subject (n) is the packet
delivery testing, rater (r) is rater A and B. Rater A and B were implemented within the
software with a random recording flag set to record the data into matrices. The category
(q) is defined as follows: Category 1 is that both Rater A and Rater B agreed on the
packets delivery of the test system. Category 2 is that both Rater A and Rater B do not
agree on the packets delivery. Category 3 is that either Rater A or Rater B did not rate the
packets delivery. Total sample size used was 100.
Based on the use of Kappa calculation explained in research methodology, the
experiment showed the Kappa value of 0.517 as seen in Table 3. 75 of the samples were
rated as category 1 or both Rater A and Rater B, which shows the raters agree above
chance (67.1) on packet delivery for single protocol in 3 minutes runtime. Eight of the
samples were rated as category 2 for both Rater A and Rater B, which shows the raters
not agreed on the given samples. Both raters had disagreement and Rater A rated 3 of the
samples for category 2, while Rater A rated the same samples category 1. Both Rater A
and Rater B did not rate 2 of the samples and it is category 3. Kappa estimates that
agreement level beyond chance and estimate 0.517, with standard error of 0.104, and
0.0000 for significant error.

Table 3 Kappa coefficient analysis
Cases
Valid Missing Total
N Percent N Percent N Percent
Rater A * Rater B 100 55.2% 81 44.8% 181 100.0%
Rater A * Rater B cross tabulation
RaterB
1 2 3
Total
Count 75 3 0 781
Expected count 67.1 9.4 1.6 78.0
Count 6 8 0 142
Count 5 1 2 8
Rater A
3
Count 86 12 2 100Total
Expected count 86.0 12.0 2.0 100.0
Symmetric measures
Value Asymp. std. error Approx. T Approx. sig.
Measure of Kappa
agreement
0.517 0.104 6.589 0.000
N of valid cases 100
This shows that based on Landis and Koch benchmark scale; there is a moderate
agreement between Rater 1 and 2 in recording the packet delivery for 3-minutes runtime.
Although, initially in this research we were expecting to get a number close to 40%, to
accept a fair agreement, but we received above 51% for Kappa which pushed the
agreement level to moderate.
In packet delivery ratio testing, the two different industrial Ethernet protocols used in
this research behaved differently in packet delivery. The Profinet RT and Powerlink
protocols’ delivery rate were different. Figure 4 packet delivery ratio shows that Profinet
RT (single protocol) was performing better than the network configured with Profinet RT
and Powerlink protocols (disparate protocols).

Table 4 Packet loss
T-test
Groupstatistics
ValuessingleNMeanStd.deviationStd.errormean
128663.0633.1231.959Packetloss
single21373.7741.71611.570
Independentsamplestest
Levene’stestfor
equalityofvariances
T-testforequalityofmeans
95%confidenceinterval
ofthedifferenceFSig.tdf
Sig.
(2-tailed)
Mean
difference
Std.error
difference
LowerUpper
Equalvariances
assumed
4.9720.027–1.1272970.261–10.7139.504–29.4177.990Packetloss
single
Equalvariancesnot
assumed
–0.91312.6970.378–10.71311.734–36.12614.699

Through the simulation, the first research question ‘What are the benefits and drawbacks
of applying standardised common protocols to support communication types in the
industrial Ethernet environments?’ was shown by the test data when disparate protocols
were used the packet loss was higher than with the same protocol. The benefits that
would be seen by the same protocol are response times would improve and
communications would not be the leading cause of machine stoppage. The drawback
realised is the development life cycle time to create a protocol is approximately ten years.
Once the theory is proven then the product development life cycle can be five to ten years
(Leiner et al., 2013).
Figure 3 Packet loss comparison multi-protocol vs. single protocol 3-min runtime (see online
version for colours)
Figure 4 Packet loss comparison multi-protocol vs. single protocol 6-min runtime (see online
version for colours)
The packet loss comparison in the testing network under various simulation scenarios
using different protocols is presented below. Each figure represents the packet loss
comparison for the run time allocations of three, six and nine minutes. It can be observed

from the figures below that in all of the testing scenarios with various traffic loads, the
packet loss in the single protocol testing was relatively low. When the traffic load
increased, the drop was significantly higher in the network containing disparate protocols
than in the network containing the single protocol.
The SPSS software package was used to analyse the data to answer the research
question number two, if there is significant evidence that the packet loss ratio with the
same protocol is less than packet loss of disparate protocol. We have two sample means
that are independent; the sample data for single protocol is independent of the sample
data for disparate protocol in our test. For the null hypothesis ‘common protocols
architecture to support disparate communication types in the industrial Ethernet
environments have no direct impact on machine communication and availability of the
network’, through the independent T-test, if the absolute value of the obtained r is less
than the r-critical, then retain the null hypothesis and conclude that there is no linear
relationship between the packet loss in a single protocol environment and packet loss in a
multi-protocol environment in the population represented in the sample. For the alternate
hypothesis ‘common protocols architecture to support disparate communication types in
the industrial Ethernet environments have a direct impact on machine communication and
availability of the network’, if the absolute value of the obtained r is greater than the
r-critical, conclude that there is a linear relationship between the packet loss in a single
protocol environment and packet loss in a multi-protocol environment in the population
represented in the sample based on the mean and standard deviation of single protocol,
and multi-protocol packet losses. The independent T-test supported the research
hypothesis that the packet loss in a single protocol environment and packet loss in a
multi-protocol environment in the population represented in the sample was a positively
correlated relationship. The direction of the correlation in the population represented in
the sample was a positively correlated relationship. Therefore, a single protocol
environment has less packet loss, which supports the objective of this research. For this
research, the testing concluded that the research hypothesis is supported, because the null
hypothesis was rejected, and the obtained r value agrees with the linear relationship
hypothesised by this research.
Figure 5 Packet loss comparison multi-protocol vs. single protocol 9-min runtime

Table 5 T-test 1
T-test
Groupstatistics
ValuesmultiNMeanStd.deviationStd.errormean
5239105.1363.7764.125Packetloss
multi460125.6257.1757.381
Independentsamplestest
Levene’stestfor
equalityofvariances
T-testforequalityofmeans
95%confidenceinterval
ofthedifferenceFSig.tdf
Sig.
(2-tailed)
Mean
difference
Std.error
difference
LowerUpper
Equalvariances
assumed
0.2110.647–2.2702970.024–20.4919.028–38.258–2.725Packetloss
multi
Equalvariancesnot
assumed
–2.42399.2160.017–20.4918.456–37.269–3.713

Since the Sig p-value 0.647 for the F-test is greater than 0.05, the variance is assumed to
be equal. The significance value being 0.647 proves the variance is beyond equal. This
variance proves the facts to support the hypothesis of this dissertation. Since the
Sig 0.027 for the F-test is less than 0.05, then we can reject the null, which means that the
mean number packet loss for single-protocol is not equal to mean number of packet loss
for multi-protocol. We conclude that there is significant evidence to support the research
question that the packet loss ratio with the same protocol is less than packet loss of
disparate protocol. This concludes that the system with the single protocol performed
satisfactory to address the research question number two.
For the statistical analysis to answer the research question three, samples at random
from different testing scenarios were selected to compare the variance of a single
protocol system with multi-protocol system using variances test, and to compare the
mean processing time for those two systems using a one-sample t-test.
Table 6 One sample T-test
T-test
One-sample statistics
N Mean Std. deviation Std. error mean
Received packet
single protocol
30 0.41677 0.338561 0.061813
Received packet
multi protocol
30 0.47844 0.316438 0.057773
One-sample test
Test value = 0
95% confidence interval of
the differencet df
Sig.
(2-tailed)
Mean
difference
Lower Upper
Received packet
single protocol
6.742 29 0.000 0.416767 0.29035 0.51319
Received packet
multi protocol
8.281 29 0.000 0.478437 0.36028 0.59660
The total processing time for a single protocol system was 180 seconds.
As seen in Figure 6, the amount of packets received for single protocol was about
25% higher than multi-protocol. The results showed the total processing time for a single
protocol system is higher than that for a multi-protocol system. The end-to-end latency of
each simulation scenario is shown in Figure 7. The end-to-end latency is the difference
between the time stamp when a data packet leaves a source node and the time stamp it
arrives at the destination.
Within the testing procedure the results were as expected whereas the same protocol
packet loss was minimal and did not affect the machine up time, and when introduced
disparate protocols the packet loss was substantial enough to stop the machine. The test
units simulate a water treatment facility. The product was chosen for this simulation so
that on a small scale the simulation would be representative of a larger system.
In order to assure that these test results can be mirrored for repeatability, the test
diagrams, technical specifications, and logic operations were specifically followed in a

repeatable manner. This gives validity to the data that was collected as well as gives
future researchers the opportunity to dissect the information in order to begin the
mapping process for an all inclusive industrial protocol for the future.
Figure 6 Packets received comparison (see online version for colours)
Figure 7 End-to-end latency (see online version for colours)
The testing began with a closed-loop system in order that more packets would be
distributed and therefore error rate could be realised. Within the closed-loop system, the
process will infinitely run until stopped by the operator. For the purpose of this testing,
the machine was set to run three different timing sequences. The times for this control
process were three, six, and nine minutes. These time variables allow for consistent
process loops to run and for the capturing of the packet loss in order to realise the amount
of packet loss for same protocols verses disparate protocols. The variable that was
recorded next was the packets lost for all control variables that were transmitted onto the
network backbone.

5 Conclusions
In a dynamic and inter-organisational setting, the common communication protocols
become key challenges. The lack of standardised common protocol for communication
types within industrial Ethernet environments translates to loss of revenue for
manufacturing companies. The motivation behind applying a common protocol to
support disparate communication types is to investigate if such will provide the relevant
data OEM builders and manufacturing companies would need to reduce overhead and
streamline the communication process.
The communication problems between systems create overhead costs and are a result
of using multiple protocols for communication. Managing networks with various
protocols is challenging. Legacy systems are costly to maintain and are a major cost to
overhead through downtime of the machines. Within the prior works of other researchers,
many methodologies were revealed for solving the issue of disparate communication
within an industrial network. However, the results from those studies revealed that no
single solution was discovered to solve this issue. Within this dissertation, markers were
revealed through analysis of data collected from an industrial network. Evaluation of this
data revealed the need for a common protocol.
There are many research projects on real-time communication type that offer new
techniques for evaluating industrial Ethernet performance, proposals for massive
movement from hub- and cable-based Ethernet to switched fast Ethernet in office
automation, application-to-application characteristics of industrial Ethernet, internet
protocols, and efficient solutions. Ethernet is one of the most widely used local area
networking (LAN) technologies in the world today. Several approaches and techniques
have been used to make Ethernet deterministic. In today’s’ manufacturing
communication systems, Ethernet is used at all levels in a factory.
In the attempt to find solutions to the communication issues, some industrial networks
are utilising layer-3 switch for real-time communication. This adds to the complexity and
overhead costs to maintain the networks. A plethora of contributions showed that
switched Ethernet is well applicable as an automation infrastructure both with respect to
real-time characteristics in industrial Ethernet. The layer-2 switches were used in the
simulated network for this research to mimic a real network setup to perform the
experiments.
Non-real-time applications make use of the Ethernet protocols as defined in ISO
8802-3 and the TCP/UDP/IP protocol suite. The qualification for a non-real-time is UDP
type traffic. This is any communication type that does not have clocking associated with
it. Ethernet is actually classified as non-real-time communication. Within an industrial
network, many devices send broadcasts utilising UDP. This can significantly affect
network availability.
The prior works of others on industrial Ethernet are classified into areas of
communication types, protocols, topology designs, architectural and network designs.
Many of the methods, theories and techniques discussed within this dissertation may be
difficult to apply collectively in every real-world situation. The major limitation in this
research is the use of a small setting simulated industrial network verse utilising a
full-blown manufacturing network that has many stations, devices, and nodes that are
added or removed. A large setup could add more cost and longer time to simulate the

network to collect data. The main assumptions in this research relate to the environment
in which the testing was performed. It was assumed that:
• Stations, devices, and nodes cannot be added or deleted from the network during
testing.
• Configuration of devices would not be modified during simulation runs.
The testing data extracted from the simulated design provides the evidence supporting the
use of a common protocol to support disparate communication types within industrial
Ethernet environments. Each simulation was executed for a minimum of 180 seconds to
allow at least 1,200 packets to be transmitted; some may not arrive at the destination
owing to packet loss. Packet size of 512 bytes is used for fixed packet size which is
standard for transmission within an industrial network. For the statistical analysis to
answer the research questions, there were three run times done with the test units which
were three, six and nine minute times. From those times, 30% of the data was selected for
samples at random from these different testing scenarios. This method was needed to
compare the variation of the two different protocols using 1-variances test and to
compare the mean processing time for two different protocols using a 1-sample t-test.
The collection of data gathered during simulation runs was the number of packets
transmitted, the speed of transmissions, and the number of completed and failed
transmissions. The purpose of collecting these data points was to analyse the reliability of
the system and to discern any significant effect on data transmission when a common
protocol is used verses disparate protocols. The metrics used to analyse the testing were
packet delivery ratio, end-to-end latency, and control overhead.
For testing purposes, two test units were created to simulate a smaller scale network
that would be utilised within a water treatment plant. Within the testing parameters, two
protocols were used which were Profinet RT and Powerlink. The reason for choosing
these particular protocols is to show the difference in communication time to packet loss
between using the same protocol verse disparate protocol. By doing so, all of the research
questions can be realised. Another reason for choosing these particular protocols is for
future research to be able to utilise this data in order to dissect these two particular
protocols for the creation of a future all inclusive protocol.
Through the simulation and the use of SPSS software package, the first research
question ‘What are the benefits and drawbacks of applying standardised common
protocols to support communication types in the industrial Ethernet environments?’ was
answered. Shown by the test data when disparate protocols were used the packet loss was
higher than with the same protocol. The benefits that would be seen by the same protocol
are response times would improve and communications would not be the leading cause of
machine stoppage. The drawbacks realised is the development life cycle time to create a
protocol is approximately ten years. Once the theory is proven then the product
development life cycle can be five to ten years.
The SPSS software package was used to analyse the data to answer the research
question number two ‘What is the ratio of packet loss with the same protocol vs. packet
loss using different protocol?’ We have two sample means that are independent; the
sample data for single protocol is independent of the sample data for disparate protocol in
our test. For the null hypothesis ‘Common protocols architecture to support disparate
communication types in the industrial Ethernet environments have no direct impact on
machine communication and availability of the network’, through the independent T-test,

if the absolute value of the obtained r is less than the r-critical, then retain the null
hypothesis and conclude that there is no linear relationship between the packet loss in a
single protocol environment and packet loss in a multiprotocol environment in the
population represented in the sample.
For the alternate hypothesis ‘common protocols architecture to support disparate
communication types in the industrial Ethernet environments have a direct impact on
machine communication and availability of the network’, if the absolute value of the
obtained r is greater than the r-critical, there is a linear relationship between the packet
loss in a single protocol environment and packet loss in a multi-protocol environment in
the population represented in the sample. Based on the mean and standard deviation of
single protocol, and multi-protocol packet losses, the independent T-test supported the
research hypothesis that the packet loss in a single protocol environment and packet loss
in a multi-protocol environment in the population represented in the sample was a
positively correlated relationship. The direction of the correlation in the population
represented in the sample was a positively correlated relationship. Therefore, a single
protocol environment has less packet loss that supports the objective of this research. For
this research, the testing concluded that the research hypothesis is supported, because the
null hypothesis was rejected, and the obtained r value agrees with the linear relationship
hypothesised by this research.
For the statistical analysis to answer the research question three ‘What is the total
processing time in an environment with the same protocol vs. different protocol?’
samples at random from different testing scenarios were selected to compare the variance
of a single protocol system with multi-protocol system using one-variances test, and to
compare the mean processing time for those two systems using a one sample t-test.
The analysis of lost packets to time revealed the issues between a single protocol and
disparate protocol. The percentage of lost packets was considerably higher in the network
that had disparate protocols. Industrial networks require maximum up time. The network
was designed such that it mirrored and actual working industrial network. The trending of
the machine processes allowed the options of monitoring a single protocol and then
disparate protocols. The detailed analysis of the simulation results is presented from both
quantitative perspectives. The findings of this research points at the fact that by proposing
a single common protocol we could make today’s industrial network more self-reliant. In
order to understand the fundamental reasons, this research dissected a simulated
industrial network to reveal the issues surrounding disparate protocol usage. For future
researchers, the development of a common protocol will be indispensable in a context
where distributed industrial networks are common. It is then essential to propose a new
distributed infrastructure with a single common protocol for industrial networks to handle
various distributed services.
The data provides a guideline for the common protocol design and future
enhancements. The proposed idea allows a better method of communication between a
large numbers of networked devices in an industrial setting. A methodology to
investigate the performance of common protocol in industrial Ethernet networks still
leaves many uncovered areas such as scalable and routing and mobile nodes and devices
for very large-scale networks. All of these aspects were outside the scope of this
dissertation. The contributions of this research toward the greater body of knowledge are
realised by revealing the need to improve common protocols for communication types in
industrial Ethernet environments. Reliability and validity is imperative and therefore the

industrial network that was created for this research can be duplicated. This will give
future researches a road map in which to begin the creation of an all inclusive protocol.
References
ABB (2012) Industrial Automation PLC, Control Panels, SCADA, Engineering Software, Wireless
[online] http://www05.abb.com/global/scot/scot209.nsf/veritydisplay/
4446f12da27ab972c1257ac500510c98/$file/1SBC125003C0205.pdf (accessed 20 May 2014).
Carvajal, G. and Fischmeister, S. (2013) ‘An open platform for mixed-criticality real-time
Ethernet’, Design, Automation & Test in Europe Conference & Exhibition (DATE),
18–22 March, pp.153–156.
Decotignie, J.D. (2009) ‘The many faces of industrial Ethernet’, IEEE Ind. Electron. Mag., Vol. 3,
No. 1, pp.8–19.
Felser, M. and Sauter, T. (2002) ‘The fieldbus war: history or short break between battles?’, in
Proc. IEEE Int. Workshop Factory Communication Systems (WFCS), pp.73–80.
Haley, S.M. and Osberg, J.S. (1989) ‘Kappa coefficient calculation using multiple ratings per
subject: a special communication’, Physical Therapy, Vol. 69, No. 11, pp.970–974.
Ismail, N. and Paquin, R. (2012) Industrial Ethernet Gaining Ground in Manufacturing [online]
http://www.automation.com/content/industrial-ethernet-gaining-ground-in-manufacturing
(accessed 26 March 2014).
Landis, J.R. and Koch, G.G. (1977) ‘The measurement of observer agreement for categorical data’,
Biometrics, March, Vol. 33, No. 1, pp.159–174, International Biometric Society Stable
[online] http://www.jstor.org/stable/2529310 (accessed 20 May 2014).
Leiner, B.M., Cerf, V.G., Clark, D.D., Kahn, R.E., Kleinrock, L., Lynch, D.C., Postel, J.,
Roberts, L.G. and Wolff, S. (2013) Brief History of the Internet [online]
http://www.internetsociety.org/internet/what-internet/history-internet/brief-history-internet
(accessed 6 March 2014).
Löser, J. and Hártig, H. (2004) ‘Low-latency hard real-time communication over switched
Ethernet’, in Proc. 16th Euromicro Conf. Real-Time Systems, ECRTS 2004, 30 June–2 July,
pp.13–22.
Moyne, J.R. and Tilbury, D.M. (2007) ‘The emergence of industrial control networks for
manufacturing control, diagnostics, and safety data’, Proc. IEEE, Vol. 95, No. 1, pp.29–47.
Vaclav, S. (2006) Transforming the Twentieth Century: Technical Innovations and Their
Consequences, p.173, Oxford University Press, Oxford, New York.
Woods, J. (2011) Minimizing Contributions to System Delay from NIC Packet Processing in CIP
Motion and other Real-Time Control Applications [online] http://odva.org/Portals/0/Library/
Annual%20Meeting%202011/2011_ODVA_Conference_Minimizing_Contributions_to_
System_Delay_Paper.pdf (accessed 16 August 2014).
Zanchi, A. (2012) Industrial Automation and Process Control – The Big Three Predictions by
Frost & Sullivan [online] http://www.frost.com/prod/servlet/press-release-print.pag?docid=
260948707 (accessed 14 March 2014).
Zhang, M., Shi, J., Zhang, T. and Hu, Y. (2008) ‘Hard real-time communication over multi-hop
switched Ethernet’, International Conference on Networking, Architecture, and Storage, 2008,
NAS ‘08, 12–14 June, pp.121–128, DOI: 10.1109/NAS.2008.31.

Common protocol to support disparate communication types within industrial Ethernet environments

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (20)

Similar to Common protocol to support disparate communication types within industrial Ethernet environments

Similar to Common protocol to support disparate communication types within industrial Ethernet environments (20)

More from Maurice Dawson

More from Maurice Dawson (20)

Recently uploaded

Recently uploaded (20)

Common protocol to support disparate communication types within industrial Ethernet environments