23.03.2017 Views

wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

39-10 Industrial Communication Systems<br />

Indeed, the size of each <strong>communication</strong> slot depends on the amount of data transmitted as well as on the<br />

network topology and latency induced by the network components, which therefore also influence the<br />

cycle time. Moreover, the adoption of the multiplexed <strong>communication</strong> class (either alone or in conjunction<br />

with the continuous one) allows to reduce the maximum number of slots in each cycle and consequently<br />

the cycle time as well.<br />

Finally, it is also important to remember that the CNs have also to perform some protocol-related<br />

tasks like, for example, SoC processing or the maintenance of the EPL cycle state machine. Thus, the time<br />

required to handle the different node activities also has to be considered. In this context, the EPL protocol<br />

provides a (limited) level of control since it allows the MN to control the poll order permitting, for example,<br />

to avoid polling the CNs with highest SoC latency immediately after the sending of the SoC frame.<br />

39.7.4 acyclic Traffic<br />

According to the EPL specification, the asynchronous period aims at the transfer of non time-critical<br />

data, typically related with the network management and supervision (ASnd messages) as well as with<br />

non-EPL traffic (e.g., TCP or UDP/IP messages). Despite not being addressed in the EPL specification,<br />

the use of asynchronous services for carrying infrequent real-time data, e.g., alarms, could also bring<br />

efficiency gains provided that suitable latency values can be guaranteed.<br />

The latency associated with the asynchronous traffic is a relevant performance figure since it is<br />

important to have acceptable response time in the network management services as well as on the user-level<br />

applications supported on IP traffic.<br />

The latency experienced by asynchronous requests depends on the cycle duration, on the period of<br />

the real-time data associated with the CN, and on the particular scheduling algorithm used by the MN.<br />

The cycle duration defines the number of requests that can be handled by time unit. The period of the<br />

real-time data associated with the CN constraints the signaling latency since CNs notify the MN about<br />

the existence of requests via PRes messages. Thus, in the worst-case situation, the CN may have to wait<br />

one entire poll period prior to be able to inform the MN of the existence of requests. Finally, the latency<br />

also depends on the scheduling decisions at the MN. The user can influence these decisions by assigning<br />

higher priorities to the more time-sensitive asynchronous messages.<br />

As an example, an EPL network in which N different asynchronous requests occur at the same time<br />

at one or more CNs can be considered. The CNs can only notify that event to the MN in the following<br />

cycle, and the MN shall schedule at most one request in each following cycle, thus requiring a total of<br />

N + 2 cycles to handle all the requests. It has to be noticed that the number of cycles necessary to process<br />

the pending requests does not depend on the cycle duration; thus decreasing the cycle time (if possible)<br />

leads to shorter response times.<br />

On the other hand, the latency of acyclic messages could be reduced, allowing multiple ASnd transmissions<br />

in the same cycle. This is actually addressed by the latest version of the EPL specification [6],<br />

which makes such an opportunity possible, provided that there is enough remaining time in the cycle.<br />

Another possible way of improving the response time for asynchronous time-sensitive messages would<br />

consist in reserving part of the asynchronous phase exclusively for alarms, as discussed in [13].<br />

References<br />

1. Bernecker & Rainer Industrie-Elektronik GmbH, Eggelsberg, Austria [Online]: http://www.brautomation.com<br />

2. Ethernet POWERLINK Standardization Group. [Online]: http://www.ethernet-powerlink.org<br />

3. IXXAT Automation GmbH: POWERLINK interface board for PCI bus <strong>systems</strong> PL-IB 200/PCI,<br />

Technical description. [Online]: http://www.ixxat.com/powerlink_pci_interface_en.html<br />

4. OpenPOWERLINK: Open source solution for POWERLINK MN and CN. [Online]: www.sourceforge.<br />

net/projects/openPOWERLINK<br />

© <strong>2011</strong> by Taylor and Francis Group, LLC

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!