134
Int. J. Network Science, Vol. 1, No. 2, 2016
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:
[email protected]
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:
[email protected] *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.
Copyright © 2016 Inderscience Enterprises Ltd.
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.
Common protocol to support disparate communication types
137
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
138
J. MacPherson and M. Dawson
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
Common protocol to support disparate communication types
139
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:
140
J. MacPherson and M. Dawson
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
Common protocol to support disparate communication types
141
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.
142
J. MacPherson and M. Dawson
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)
Common protocol to support disparate communication types Figure 2
143
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.
144 Table 3
J. MacPherson and M. Dawson Kappa coefficient analysis Cases Valid
Rater A * Rater B
Missing
Total
N
Percent
N
Percent
N
Percent
100
55.2%
81
44.8%
181
100.0%
Rater A * Rater B cross tabulation RaterB Rater A
1
2
3
75
3
0
78
67.1
9.4
1.6
78.0
6
8
0
14
12.0
1.7
0.3
14.0
5
1
2
8
Expected count
6.9
1.0
0.2
8.0
Count
86
12
2
100
86.0
12.0
2.0
100.0
Count Expected count
2
Count Expected count
3 Total
Total
1
Count
Expected count
Symmetric measures Measure of Kappa agreement N of valid cases
Value
Asymp. std. error
Approx. T
Approx. sig.
0.517
0.104
6.589
0.000
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).
Packet loss single
Packet loss single
Equal variances not assumed
Equal variances assumed
13
4.972
F 0.027
Sig.
Levene’s test for equality of variances
286
1
N
2
Values single
–0.913
–1.127
t
12.697
297
df
Independent samples test
73.77
63.06
Mean
Group statistics
0.378
0.261
Sig. (2-tailed)
–10.713
–10.713
Mean difference
11.734
9.504
Std. error difference
T-test for equality of means
41.716
33.123
Std. deviation
–36.126
–29.417
Lower
14.699
7.990
Upper
95% confidence interval of the difference
11.570
1.959
Std. error mean
Table 4
T-test
Common protocol to support disparate communication types Packet loss
145
146
J. MacPherson and M. Dawson
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
Common protocol to support disparate communication types
147
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
Packet loss multi
Packet loss multi
Equal variances not assumed
Equal variances assumed
60
0.211
F 0.647
Sig.
Levene’s test for equality of variances
239
5
N
4
Values multi
–2.423
–2.270
t
99.216
297
df
Independent samples test
125.62
105.13
Mean
Group statistics
0.017
0.024
Sig. (2-tailed)
–20.491
–20.491
Mean difference
8.456
9.028
Std. error difference
T-test for equality of means
57.175
63.776
Std. deviation
–37.269
–38.258
Lower
–3.713
–2.725
Upper
95% confidence interval of the difference
7.381
4.125
Std. error mean
Table 5
T-test
148 J. MacPherson and M. Dawson
T-test 1
Common protocol to support disparate communication types
149
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 t
df
Sig. (2-tailed)
Mean difference
95% confidence interval of the 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
150
J. MacPherson and M. Dawson
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.
Common protocol to support disparate communication types
5
151
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
152
J. MacPherson and M. Dawson
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,
Common protocol to support disparate communication types
153
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
154
J. MacPherson and M. Dawson
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.