Real Time Ethernet Networks Evaluation Using Performance Indicators

Transcription

1 Real Time Ethernet Networks Evaluation Using Performance Indicators L. Seno, S. Vitturi Italian National Council of Research CNR-IEIIT Department of Information Engineering, University of Padova Via Gradenigo 6/B, I Padova, Italy C. Zunino Italian National Council of Research CNR-IEIIT Corso Duca degli Abruzzi 24, I Torino Italy Abstract The employment of Real Time Ethernet networks in factory automation systems is rapidly increasing and several commercial products, with different characteristics, are already available from various manufacturers. Most of these networks have been included in both the IEC and IEC International Standards that, in addition, define a set of Performance Indicators. In this paper we focus on two popular Real Time Ethernet networks, namely Ethernet POWERLINK and, and we evaluate their performance for a typically deployed factory automation configuration. Specifically, we compute the most relevant performance indicators introduced by IEC standard and two (purposely defined) additional ones, namely minimum cycle time and jitter, which are suitable for the two networks considered. 1. Introduction Real Time Ethernet (RTE) networks [11] are even more deployed in factory automation systems thanks to their features, that allow to achieve significant performance improvements with respect to the communication systems traditionally employed in the past. Most of the available RTE networks are encompassed by both the the IEC [4] and IEC [9] International Standards. Besides defining the real time profiles, IEC introduces a set of performance indicators (PIs) which are meant to specify capabilities of an RTE end device and an RTE communication network as well as to specify requirements of an application. As discussed in [12], these PIs are noticeably helpful. Nevertheless, in some cases they may result not completely exhaustive for the users, due to their general definition. For example, it is well known that several industrial applications require the cyclic delivery and/or acquisition of data (this feature, actually, is provided by all RTE networks). However, specific PIs, capable of exactly characterize such a type of operations, have not been defined since, likely, they could not be applicable to all networks of the IEC Standards. In this paper we consider two widespread RTE networks, namely Ethernet POWERLINK [6] and [5], and we provide an analysis which allows to compute their most significant performance indicators. Specifically, we refer to some PIs of the IEC Standard as well as to some additional ones which we will explicitly define for the addressed networks (that, however, may be used for other RTE communication systems). Clearly, the evaluation of the performance indicators depends on several factors related to the specific applications; in particular, the PIs are strongly influenced by the network configurations, as well as by the amounts of data exchanged. Consequently, in our analysis we will focus on a specific configuration, namely a one level architecture, comprising a single intelligent device (the controller) and some passive devices (sensors/actuators) [14], which represents by far the most deployed type of configuration at the low levels of factory automation systems [16]. The methodology used for the analysis carried out in this paper, however, is not tailored to the specific configuration we considered and, as such, it could be extended to several different cases. Finally, it is worth stressing that the paper is not meant as a tool of comparison between the two networks considered but, rather, it aims at providing some useful insights in the context of RTE performance evaluation which, sometimes, may result quite confused (possibly due to relevant commercial interests). In detail the paper is structured as follows. Section 2 gives a short description of the two networks considered. Section 3 describes the PIs of the IEC Standard and, subsequently, it introduces the on purpose defined PIs which will be additionally considered in the paper. Section 4 illustrates the network configuration. Section /09/$ IEEE

2 5 presents the results obtained by the analysis carried out. Section 6 concludes the paper and discusses some issues related to future developments. 2. Basic Description of Ethernet POWER- LINK and 2.1. Ethernet POWERLINK Ethernet POWERLINK (EPL) was originally developed by B&R GmbH [1] and it is currently managed by the Ethernet POWERLINK Standardization Group (EPSG) [2]. EPL has been designed as a data link layer protocol placed on top of the legacy Ethernet medium access control sub layer, whereas, at the application layer, EPL employs the well known CanOpen profiles [3]. Two types of stations are defined, namely, Managing Node (MN) and Controlled Nodes (CNs). The MN, which represents the controller, is unique within the network, whereas up to 240 CNs may be employed connected in various configurations. The interconnection between network devices may be realized either via hubs or switches (although the standard actually recommends the use of hubs). The EPL data link layer protocol is based on a master slave relationship realized by means of a continuously repeated sequence of operations (the EPL cycle) described in Fig. 1. The cycle is started by the MN which broadcasts the Start of Cycle (SoC) frame. Then, the Isochronous Period is entered where the MN polls the CNs. In this phase the MN issues a PReq (Poll Request) frame carrying the output data to each CN which, consequently, responds with a PRes (Poll Response) frame containing the input data. PRes frames are broadcasted on the network so that each station may read the input data transmitted by any CN. Once the CNs have been polled, the MN may optionally broadcast a PRes frame before the end of the isochronous period. Subsequently, the MN sends the SoA (Start of Acyclic) frame to notify the beginning of the Acyclic Period to the CNs. This frame allows to grant either a single CN or the MN itself with the access to the network for the transmission of only one acyclic message. According to the standard, two types of asynchronous frames may be transmitted, namely Powerlink ASnd (Asynchronous Send) and Legacy Ethernet messages. Finally, the Idle Period is entered, where the MN waits for the remaining time before starting a new cycle. It is worth observing that not all the CNs are necessarily polled at each EPL cycle. Indeed, the standard supports two communication classes, respectively referred as continuous and multiplexed, which specify the way in which CNs are addressed. In the continuous class a CN is polled at every cycle, whereas in the multiplexed class a CN is polled every n cycles (with n>1). Both the communication classes may be handled contemporaneously in a EPL cycle so that it results possible to have a polling scheme in which some CNs are queried continuously (i.e. Startt Asynchronous Idle Isochronous Period Period Period Period MN MN MN MN MN MN MN or CN #x PReq/PRes Asnd or SoC PRes SoA Ethernet All CNs CN #1 CN #2 CN #n All CNs All CNs Ethernet Powerlink Cycle Figure 1. Ethernet Powerlink Cycle every EPL cycle) whereas some others are polled with a period which is a multiple of the EPL cycle. The duration of the EPL cycle can be trivially evaluated as the sum of the periods shown in Fig. 1: T epl C = T st + T is + T as + T id (1) In equation (1), T st is the duration of the start period, expressed as the time necessary to send the SoC frame plus a safety margin necessary to ensure that all nodes are ready for the beginning of a new cycle. T is and T as are, respectively, the duration of the isochronous and asynchronous periods, T id is the idle time. Both T is and T as depend on the amount of data exchanged as well as on the network configuration. Specifically, the duration of the isochronous period can be expressed as: T is = T rq + T rs + D mn + D cn + D nk (2) where T rq is the time necessary to the MN to send all the PReq frames; similarly, T rs is the time employed by the CNs to send the PRes frames. D mn and D cn are, respectively, the delays introduced by the MN and the CNs. For example, when the MN receives a PRes frame from a CN, it has to wait for a quiet time before moving on the next CN (this time is referred as t PRs PRq in [6] with a typical value of 1 μs). Finally, the term D nk in equation (2) accounts for the delay introduced by all the network components, including latencies, propagation times, etc. The duration of the asynchronous period is given by: T as = T sa + T fr (3) where T sa is the time necessary to transmit the SoA frame and T fr is the time necessary to complete the single transmission allowed in this period is a master/slave network which uses, at the data link layer, a summation frame technique. In practice, during the functioning of, a single frame periodically issued by the master station circulates among all the slaves. At the arrival of the frame, each slave extracts the output data addressed to it and inserts the input data for the master. These operations are carried out on the fly, i.e. while the frame is crossing the slave and,

3 Standard Ethernet Protocol Data Unit Master Slave 1 Slave N Number of Bytes Preamble Start Frame Delimiter Destination Address Source Address EtherType Ethernet Payload Frame Check Sequence Up to Figure 2. Example of Configuration Number of Bytes Header 2 #1 Frame #2 #N hence, the frame itself is not received and subsequently retransmitted but, rather, it just passes through the slave. When the frame reaches the last slave, it is redirected towards the master as shown in Fig. 2, which reports an example of network configuration. Consequently, stations (either master or slaves) have to be full duplex devices, i.e. capable of receiving/transmitting data concurrently. uses standard Ethernet frames which, similarly to EPL, encapsulate the telegrams specifically defined by the protocol, as shown in Fig. 3. This allows, from an implementation point of view, that the master is a common Ethernet node running the protocol. Conversely, the on the fly elaboration which has to be provided by the slaves, requires that these devices are equipped with special hardware components which make them quite different from legacy Ethernet nodes. Fig. 3 also shows the structure of the telegrams contained in the Ethernet data field. As can be seen, a telegram begins with a 10 byte header that, in particular, specifies the type of operation for which it is intended (for example read, write, read/write, etc.). The header is followed by the data field which represents the area in which slaves write and/or read plant data during the network operation. Finally, the working counter is a 2 byte field employed by the master to check for the correct execution of the operation specified in the header field. Typically, telegrams are employed for exchanging real time data between master and slaves. However, networks are able to cope with non real time traffic as well. This may take place by means of mailboxes, which are specific structures that may be fitted within an Ether- CAT telegram. In this way, for example, a TCP/IP protocol data unit can be inserted inside a mailbox. Ether- CAT makes use of an interesting technique, namely the logical addressing, in order to implement an effective data exchange between master and slaves. With such a mechanism, slaves are not directly addressed by the master but, rather, they read/write actual plant data from/to a logical memory. In practice, each slave has assigned a set of fieldbus memory management units (FMMUs) which are logical structures directly mapped on the slave physical input/output data; in an telegram, the master may specify a logical address referring to several FMMUs, possibly located on different slaves. Then, during operation, each slave analyzes the logical address of the frame which is passing through: if the address matches with one or more of its FMMUs, then that slave extracts the out- Number of Bytes Header Data Working Counter 10 2 Figure 3. Structure of the Frame put data and writes the input ones. In this way, a unique header (telegram) is used to address several slaves with the consequent improvement of the protocol efficiency. An master, in principle, may issue telegrams with different periods, possibly addressing different sets of slaves. From the structure of an frame shown in Fig. 3 as well as from the theoretical analysis provided in [13], the cycle time of, T etc, may be expressed as: C TC etc = T et + T ec + T sv + T if (4) where, T et is the time necessary to transmit all fields of the frame but the payload. T ec is the time actually requested for transmitting the frame, which is encapsulated in the payload of the Ethernet frame. T sv is the delay introduced by the slaves due to the elaboration of the frame. Assuming the same delay for each slave (this is reasonable, since different slave devices likely use the same hardware for frame elaboration), we have that such a value is expressed as the sum of two components, namely, the delay introduced by the actual reading/writing operation, D rw, and the delay introduced by the regeneration of the Ethernet frame itself, D re. Since a frame is regenerated twice by each slave (on both the forward and the backward paths), then trivially we have: T sv = N (D rw +2D re ), where N is the number of slaves. Finally, T if is the time which has to be waited before issuing a new frame (referred as interframe gap in the original Ethernet specification). In eq. (4), the term T ec is specifically related to the Ether- CAT protocol and it is given by: T ec = T eh + L (T th + T wc )+ L i=1 T (i) ct (5) where T eh is the time necessary to transmit the Ether- CAT header; L is the number of telegrams within the frame. Both T th and T wc account for the transmission of, respectively, the telegram header and the working timer. T (i) ct is the time requested to transmit the data field of the i th telegram in the frame.

4 3. Performance Indicators for RTE Networks The IEC standard defines a set of Performance Indicators (PIs) in order to specify the capabilities of the RTE networks [12]. In this section we recall some of the most relevant PIs, specified by the aforementioned standard and, moreover, we introduce two new PIs, namely Minimum Cycle Time and Jitter, which reveal particularly effective in several applications for both the networks considered in this paper as well as for other RTE systems standardized by IEC PIs defined by IEC Among the PIs defined by IEC we consider those mostly related to the dynamic behavior of a RTE network, namely, Throughput RTE, Non RTE Bandwidth and Delivery Time. The Throughput RTE accounts for the ability of the network to handle real time data. Indeed, it is defined as the number of octets per second transmitted on a specific link exclusively relevant to APDUs traffic. As an immediate example of application, the Throughput RTE may be used to measure the flux of real time data between the controller and sensors/actuators. The Non RTE Bandwidth is concerned with the transmission of non real time data. It is defined as the percentage of the network bandwidth that can be used, on a specific link, for non real time traffic. Such a PI reveals helpful when general purpose traffic (e.g. TCP/IP communications) has to be handled by the network in conjunction with the real time one. The Delivery Time is defined as the time needed to convey an Application Protocol Data Unit (APDU) containing data from one node to another of the network. The delivery time is particularly suitable to evaluate, for example, the time necessary to transfer the process data provided by a sensor (either cyclically or acyclically) to a controller device PIs specifically defined Both the RTE networks considered in this paper as well as several others (for example PROFINET IO [7]) operate on the basis of a cycle, continuously executed, during which all the activities of the network nodes are scheduled. The duration of a cycle is a parameter, typically referred as cycle time, usually set by the user at the beginning of the network operation. Such a parameter, however, can not be chosen arbitrarily since it has a lower bound determined by several factors such as, for example, the network configuration, the amount of data transferred between the nodes and the latencies of the components employed. The minimum time requested to execute a cycle can be considered a crucial indicator of the overall behavior of the network as it represents the minimum amount of time which as to elapse between two consecutive execution of one cyclic action (i.e. reading/writing of data Managing Node CONTROLLER ETHERNET POWERLINK HUB CN # 1 CN #2 CN # N Figure 4. POWERLINK Configuration from/to a network node) and can thus be defined as the minimum sampling time achieved by the network system. For such a reason, we consider it as a performance indicator, namely, the Minimum Cycle Time (MCT). The duration of a cycle can be (negatively) affected by a certain degree of uncertainty due to several, possibly random, factors. Indeed, unpredictable transmission delays and/or errors (as described, for example, in [18] for a specific fieldbus) as well as latencies in the network stations and/or components, may result in fluctuations of the cycle time. Such a phenomenon is known as Jitter and we evaluate it by means of a further performance indicator defined as: J = T C TC m (6) T C where T C is the nominal cycle time (i.e. the value set at the beginning of network operation), whereas TC m is the actually measured value. Specifically, J varies over the time and may be evaluated at every cycle by any of the network nodes. 4. Network Configurations In this paper we refer to a network configuration typically deployed at the lowest level of factory automation systems which is often referred either as device or field level. In this context, only one controller is present and it is directly connected to a set of sensors/actuators by means of a field network [17, 11]. The traffic on the network is usually characterized by the transfer of limited amounts of data (some bytes per message) but, often, with very tight timing requirements (for example, network cycle times can be as low as some hundreds of microseconds). The configuration we consider for EPL is shown in Fig. 4 As can be seen, a hub device is used to connect the MN to the CNs. Clearly, the values assumed by the PIs are strictly related to the particular network configuration adopted. We decided to consider a network configuration with a limited number of slave devices as it is quite usual at the device level of factory automation systems. However the analysis we carried out is totally general and can be extended to network configurations with an arbitrary number of slaves. EPL uses standard Ethernet frames and, hence, their minimum size is 64 bytes. Such a frame size allows for the exchange of variable data fields comprised between

5 1 and 46 bytes among EPL nodes. Since the EPL protocol uses the first three bytes of the Ethernet payload, it follows that, under this assumption, EPL frames (for example PReq/PRes) may carry up to 43 bytes of useful data. Such a maximum amount is, in general, adequate to fulfill the requirements of data exchange at the device level of factory automation systems and, consequently, it will be used for EPL throughout this paper. The equivalent configuration for is shown in Fig. 2. It is represented by a linear chain which originates from the master, passes through all the slaves and returns to the master. In this case, we assume that each node exchanges 4 input bytes and 4 output bytes with the master which, again represent typical amounts of data transferred between nodes at the device level (typically corresponding to a 32 bits Integer or Float value). The most relevant parameters of the two networks used in this paper are summarized, respectively, in Table 1 for EPL and in Table 2 for. It is worth observing that the time values shown for EPL have been derived directly from the standard document [6], whereas the Ether- CAT slave delay has been obtained from [13] and experimentally validated (the delay D re has not been considered since its value is negligible). Table 1. EPL Parameters Parameter Meaning Value T st Duration of the Start Period 45 μs t PRs PRq Delay of MN per each CN 1 μs t PRq PRs Response Time of each CN 8 μs N Number of CNs 8 B in Input bytes per CN 1 43 B out Output bytes per CN 1 43 Table 2. Parameters Parameter Meaning Value D rw Slave delay 1 μs N Number of slaves 8 B in Input bytes per slave 4 B out Output bytes per slave Network Scheduling The performance of both the networks considered are heavily influenced by the scheduling techniques adopted. In particular, it is crucial to know how the passive devices are handled by the controller. Concerning EPL, as a natural choice, we assume that all CNs are polled at each cycle, implementing in such a way the continuous communication class. As far as Ether- CAT is concerned, a single frame is used containing a unique telegram which accommodates all the real-time data to/from the slaves. 5. Performance Indicators Computation 5.1. Minimum Cycle Time and Throughput RTE These two PIs are closely related. Indeed, MCT represents the minimum polling period of the slave devices. Hence, given the amount of real time data exchanged on one link, then the maximum Throughput RTE for that link is achieved when the cycle time of the network is set to the MCT value. For EPL networks, we assume that no asynchronous traffic is present and, moreover, we suppose that, among the possible choices, both the PReq and PRes frames carry 4 bytes of process data (the transmission time of one of such frames, at 100Mbits/s,is5.76 μs, since the transmissions are not consecutive and we do not take into account the IFG). The MCT has then been obtained as the sum of the durations of the first two periods shown in Fig. 1. Analogously, the MCT for is given by the time necessary to transmit the whole Ether- CAT frame (since it represents the minimum achievable period of transmission of that frame). Table 3 reports, for the aforementioned network configurations, the calculated values of both MCT and Throughput RTE. This latter has been evaluated assuming that the cycle time of both the networks is equal to MCT and it is referred to the link between the controller (either the MN or the master) and the first passive device (the value, however, is the same for all other links since the passive devices exchange the same amount of data with the controller). Table 3. MCT and Throughput RTE Performance Indicator EPL MCT μs μs Throughput RTE 38.2 kb/s kb/s The worse performance figures of EPL (compared with ) may be partially explained by the limited amount of data transmitted with the PReq/PRes frames. Clearly, since the MCT does not change if up to 43 bytes of data are carried by such frames, then the Throughput RTE of EPL increases proportionally with the number of bytes. The behavior of the Throughput RTE and of the MCT for the considered EPL network are shown in Fig. 5. As can be seen, a maximum Throughput RTE of kb/s is achieved with the same MCT shown in Table 3; the kink at 86 bytes is due to the fact that a minimum size Ethernet frame can carry up to 43 bytes of EPL data (and hence the total amount exchanged is 86 bytes if we consider both PReq and PRes frames). Increasing the number of data bytes over 43 results in a greater frame size. The EPL performance may be improved exploiting the flexibility of its scheduling scheme. For example, let us refer to an EPL cycle in which both communication classes (continuous and multiplexed) are handled contemporaneously. We assume that, in total, four CNs are polled at each cycle and that two specific CNs are polled contin-

6 Throughput RTE MCT Throughput RTE MCT 80 Throughput RTE [kbytes/s] MCT [μs] Throughput RTE [kbytes/s] MCT [μs] Transmitted data during each cycle [byte] Figure 5. Throughput RTE for EPL Transmitted data during each cycle [byte] Figure 6. Throughput RTE for uously, whereas the other ones change from cycle to cycle (such a policy requires three consecutive EPL cycles to execute a complete query of all the CNs). In this case, the minimum cycle time reduces to MCT = μs and the corresponding maximum Throughput RTE (on one of the links connecting the MN to the CNs polled continuously) results kb/s. A further improvement of the EPL performance may be achieved introducing multicast addresses. The idea behind such a strategy is that, if a specific set of data has to be sent to more than one CN, then a unique frame addressed to all the destination CNs could be used. EPL, actually, encompasses such a facility, since the PRes frame issued by the MN is broadcasted to all CNs. Thus, for instance, in the above example we could use a multiplexed cycle in which two CNs are polled per cycle and, moreover, the broadcasted PRes is issued. In this case, the minimum cycle time is MCT =88.6 μs and the maximum Throughput RTE results kb/s. However, broadcasting the PRes frame may reveal not completely satisfactory since not all CNs could need to receive it. In this case, a more efficient technique would be the actual assignment of multicast addresses to sets of CNs. Such a functionality is not provided by the EPL standard but, indeed, it might be introduced as a slight modification which maintains total compatibility with the original version. The behavior of the Throughput RTE has been evaluated for as well. The results are reported in Fig. 6. In this case there are not as many scheduling alternatives as for EPL (we may only set the transmission period of the frame which, in any case has to be greater than MCT). Nonetheless, the performance figures of this network are impressive Non RTE Bandwidth According to its definition, the Non RTE Bandwidth is evaluated as the percentage of bandwidth that may be used for non real time traffic within a cycle. Clearly, this requires that the value of the cycle time has been fixed. Thus, in order to provide a realistic example of calculation, we referred to the timing typical of the applications at the device level of factory automation systems [8] and we set for both the networks the cycle time as T C = 500 μs. Since the time necessary to transmit the real time data is given by MCT, then the Non RTE Bandwidth (NRB) can be expressed as NRB = T C MCT T C 100 (7) Since MCT depends on the amount of real time data exchanged, the same happens to NRB. More precisely, for a specific value of T C, the higher the amount of real time data, the lower the NRB. However, similarly to the Throughput RTE, for EPL networks the MCT (and hence NRB) remains constant if minimum size Ethernet frames are exchanged (i.e. if up to 43 bytes of data are exchanged between MN and CN). This is shown in Fig. 7 which reports the behavior of NRB for both the networks. As can be seen, in Fig. 7, two different scheduling schemes for EPL have been considered. In particular the term EPLcnt, refers to the continuous cycle, whereas EPL-mtx is the previously described multiplexed cycle with four CNs polled per each EPL cycle Delivery Time We evaluated the delivery time (DT) for both the networks considered relevant to the transmission of cyclic real time data from a passive device to the controller. Assuming that the data are generated at the passive device asynchronously with respect to the network cycle, then they have to wait for a random time before being picked up and transmitted on the network. Such a time is uniformly distributed between zero and the duration of the network cycle time. Thus, the delivery time is given by DT = αt C + T N (8) where T C is the cycle time, whereas α is a random variable uniformly distributed between 0 and 1. T N is the

7 Delivery Time [μs] Non RTE Bandwidth [%] EPL cnt EPL mtx ECAT Transmitted data during each cycle [byte] Figure 7. Non-RTE Bandwidth Sample Figure 8. Delivery Time 5.4. Jitter The behavior of the networks considered in this paper may by influenced by the presence of jitter in two different situations: at the beginning of a cycle and during its execution. Actually, there may be jitter at the beginning of a network cycle due to several causes. For example, if the current EPL cycle for whatever reason takes more than its expected duration, then the next one will be necessary delayed. Analogously, a task running on the master which exceeds its execution deadline, if not adequately preempted, may cause a delayed delivering of the frame, with the consequent jitter in updating the slaves. Furthermore, in EPL networks, jitter may appear during the execution of a cycle as well. Indeed, if for example a CN takes a longer interval of time to respond to the query of the MN (or, worse, it experiences a time out in issuing the PRes frame), then the following CNs will be polled with an actual period greater than the previous one. This latter type of inconvenient can not occur in networks, since the dedicated hardware implementing the on the fly elaboration prevents the introduction of random delays by the slave devices. Equation (6) is suitable to quantify both the aforementioned types of jitter and, consequently, it might be used to specify its maximum tolerable value. Finally, it is worth mentioning that the effects of the jitter (possibly) introduced by the networks are clearly related to the specific applications for which they are employed. For example, motion control applications are known to be very jitter sensitive [10], whereas traditional process control systems [15] have much more relaxed requirements. 6. Conclusion time employed by the network to actually send the data from the passive device to the controller. For EPL networks, T N is the time necessary to poll the CN that transmits the data. Such a query implies the transmission of both PReq and PRes frames as well as the response time of the CN. The resulting value is T N =18.24 μs. Conversely, for networks, T N depends on the the physical position of the slave within the network. In particular, since each slave introduces a delay (T sv ), we will have that T N = MCT etc T sv for the first slave in the chain and T N = MCT etc N T sv for the last one. The delivery time has been evaluated for an EPL network with, as in th, resulting in 500 ms simulation time. The relevant behavior is shown in Fig. 8. It has to be pointed out that T N assumes similar values for both the networks (indeed, for, considering a slave delay of 1 μs, T N ranges between 9.28 μs and μs). Consequently, if for both the networks the cycle time has been set to the same value, then the behavior of the delivery time will be practically the same. In this paper we took into consideration two RTE networks and we analyzed their performance for a specific configuration, which is widespread at the low level of factory automation system. The analysis has been carried out referring to some of the most relevant PIs introduced by IEC as well as to other purposely defined indicators. The obtained results showed that both EPL and provide very interesting performance figures particularly in term of cycle time and throughput RTE. Furthermore, the opportunity of handling non real time traffic makes RTE networks even more appealing than the traditionally used communication systems (i.e. fieldbuses). Moreover, it has been assessed that the performance of EPL could be improved either using effective scheduling strategies or, alternatively, introducing slight modifications to the protocol. Future developments, obviously, are concerned with practical measurements on the two networks which, on the one hand should validate the analysis carried out.

8 References [1] Bernecker & Rainer Industrie Elektronik GmbH: automation.com. [2] Ethernet Powerlink Standardization Group: powerlink.org. [3] Canopen application layer and communication profile, cia/ds301, version 4.01, June [4] Iec 61158: Digital data communications for measurement and control - fieldbus for use in industrial control systems - parts 2 to 6, January [5] technology group: Ethercat: Ethernet for control automation technology, [6] Ethernet powerlink standardization group: Ethernet powerlink communication profile specification v. 2.0, [7] Profibus international: Profinet IO application layer service definition, application layer protocol specification version 1.0, march 2004, [8] Industrial communication systems. In R. Zurawski, editor, The Industrial Information Technology Handbook, pages CRC Press, [9] Iec 61784: Digital data communications for measurement and control part 2: Additional profiles for iso/iec based communication networks in real time applications, november [10] F. Benzi, G. Buja, and M. Felser. Communication architectures for electrical drives. IEEE Trans. on Industrial Informatics, 1(1):47 53, February [11] J. D. Decotignie. Ethernet based real time and industrial communications. Proceedings of the IEEE, 93(6): , June [12] M. Felser. Real time ethernet -industry prospective. Proceedings of the IEEE, 93(6): , June [13] J. Jasperneite, M. Schumaker, and K. Weber. Limits of increasing the performance of industrial Ethernet protocols. In Proc. of ETFA 2007, September [14] K. C. Lee, S. Lee, and M. H. Lee. Worst case communication delay of real-time industrial switched ethernet with multiple levels. IEEE Trans. on Ind. Electr., 53(5): , October [15] B. G. Liptak. Instrument Engineers Handbook: Process Control and Optimization. CRC Press, [16] T. Sauter. The continuing evolution of integration in factory automation. IEEE Industrial Electronic Magazine, 1(1):10 19, Spring [17] J. P. Thomesse. Fieldbus technologies in industrial automation. Proceedings of the IEEE, 93(6): , June [18] A. Willig and A. Wolisz. Ring stability of the profibus token-passing protocol over error-prone links. IEEE Trans. on Ind. Electr., 48(5): , October 2001.