Image Processing Reference
In-Depth Information
26.5 IEEE 802.11-Based Extensions: RTE Networks
Despite the wide availability of both hardware components and protocols, the implementation of
wireless IEEE .-based extensions to RTE networks is not as straightforward as one could think.
Indeed, interoperability between Ethernet and WLANs is always possible by means of inexpensive
off-the-shelf devices (i.e., APs), along with some commonly available protocols like the well-known
IEEE .D bridging protocol [], which allows for interconnections at the data-link layer. Despite
the good efficiency, implementing this kind of solutions in industrial environments might be some-
times not so easy, due to access protocols adopted by RTE networks, which are often not entirely
compliant with the original Ethernet specifications. Moreover, the unavoidable uncertainty affecting
the IEEE . communication caused by the random back off procedure, interferences, and elec-
tromagnetic noise may seriously impair the determinism of the RTE networks. An example of IEEE
.-based wireless extension is provided in Ref. [] for a network different from those consid-
ered in this chapter. here, the authors refer to Ethernet Powerlink (EPL) [], a very popular RTE
networkthatadoptsanaccessprotocolbasedonafastandpreciseperiodicpollingcarriedouton
the (wired) nodes; this ensures fast operation (cycle times under  µs) and ultralow jitter (below
 µs). Results presented in the paper actually confirm the impossibility of maintaining the aforemen-
tioned tight timing performance when wireless nodes are introduced. Nonetheless, the adoption of
prioritized frames made possible by IEEE .e revealed to be quite interesting as it allows for a
consistent reduction of jitters, especially when a limited number of wireless stations are employed.
A more straightforward interconnection technique, in general, can be obtained through the com-
munication services offered by the TCP/IP protocol suite. Unfortunately, given the complexity of
TCP, this solution is not suitable for achieving real-time behavior. For such a reason, in several cases
the UDP protocol [] is preferred. UDP, in fact, has lower overheads than TCP and provides sim-
pler communication services, thanks to its unacknowledged transmission scheme (which lacks of the
sliding window mechanism of TCP). This implies that latencies and jitters become shorter than in
TCP, even though the overall behavior cannot be considered as strictly deterministic, yet.
26.5.1 Extensions of Profinet IO
The extension of Profinet IO has to face all issues discussed in the previous sections. In particular,
an extension at the data-link layer cannot be implemented, as the CSMA/CA technique employed
by IEEE . cannot cope with the very tight time schedule imposed by the TDMA medium access
technique used by Profinet IO, even if prioritized frames are used. As a consequence, the exten-
sion may only be implemented at the application layer, via a gateway, similarly to that described for
Profibus DP.
The structure of Profinet IO allows for the implementation of wireless extensions in two different
ways. When a real-time behavior is not required, the data exchange with the wireless nodes may take
place in the non-real-time period of the Profinet IO cycle (the YELLOW phase shown in Figure .).
The second option is more performing, as real-time properties can be preserved. Figure . shows
that an AP implementing the PCF technique can be used as a bridge toward the wireless segment.
Inthisway,wirelessstationscanbedirectlyincludedintheProinetIOcycle,astheAPmayassign
them specific time slots that provide contention-free, deterministic, access to the wireless medium.
However, specific actions are needed, in this case, to improve the network reliability (for example,
theadoptionofleakycables).
An example of application based on this option is provided in Ref. []. In that paper,  Profinet
IO devices are located on the wireless segment, whereas the Profinet IO controller relies on wired
connections. he bridge is a commercial product [] implementing the iPCF technique mentioned
in Section ...
Search WWH ::




Custom Search