Image Processing Reference
In-Depth Information
by the fieldbus application layer onto calls to IEEE .. services. The gateway may be typically
implemented as a station that embeds the interface to the fieldbus and, at the same time, acts as a
coordinator for the IEEE .. network.
Also in this case, the implementation of the gateway does not impose any restriction on the pro-
tocol(s) actually employed in the wireless extension. In particular, the gateway may rely on functions
provided by a proprietary protocol explicitly defined for managing data exchanges over the wire-
less extension. Alternatively, IEEE .. data-link layer services (LLC or MAC) can be directly
employed by the gateway to access wireless stations. Once again, it is worth remarking that significant
benefits can be obtained from the use of GTSs. As an example, the virtual polling algorithm described
in Ref. [] for IEEE . does not need to be implemented for IEEE .. as, in practice, such a
mechanism is natively provided by the beacon-enabled mode of the access technique.
26.6.2 Extensions of RTE Networks
The availability of the LLC protocol for IEEE .. networks could enable, in principle, the imple-
mentation of extensions to RTE networks right at the data-link layer, as most networks provide
access to such a layer as well. However, as Type  LLC services are non-confirmed, connectionless
services, there is a non-negligible probability of errors affecting communications in the wireless seg-
ment. Indeed, IEEE .. does not implement any frame retransmission technique at the MAC
level. Hence, the recovery action, which is necessary in case of frame corruption, is delegated to
upper layers. Unfortunately, the protocol is not able to detect transmission errors with the conse-
quent definitive loss of PDUs. As a conclusion, also in this case, effective extensions can only take
placeviaagateway.
Asainalremark,itisworthmentioningthatZigBee[]ofersacompleteprotocolstackbased
on IEEE .. and, consequently, it represents an appealing opportunity for implementing wire-
less extensions of both fieldbuses and RTE networks considered in this chapter. Particularly, ZigBee
offers connectivity with whatever type of networks based on the IP protocol, by means of the pur-
posely defined ZigBee expansion devices. Consequently, it can be directly interfaced to several RTE
networks (all those that allow for TCP/IP communications such as, for example, EtherNet/IP and
Profinet IO) using a conventional IP router.
26.7 Conclusions
Because of the need to provide flexible, inexpensive, and reliable communications in production
plants, it is currently envisaged that hybrid configurations resulting from wireless extensions of con-
ventional (i.e., wired) industrial networks will be adopted more and more in the next future. This
is mainly possible thanks to the availability of wireless technologies and devices able to cope with
industrial communication requirements in a proper way.
Concerningwirednetworks,theanalysispresentedinthischapterhasfocusedonfourpopular
solutions, namely, two fieldbuses (Profibus DP and DeviceNet) and two RTE networks (Profinet IO
and EtherNet/IP). In the same way, both the IEEE . family of WLAN standards and IEEE ..
WSN have been taken into account as wireless extensions, as they are some of the most promising
technologies for use in industrial automation and control applications, and a lot of devices are already
available off-the-shelf at (relatively) low cost.
As pointed out in the previous sections, the extension of Profibus DP and, in general, of almost
all fieldbuses can typically take place at the application layer, through the use of suitable proxies.
While providing greater flexibility, this may worsen the overall performance, due to delays this kind
of devices unavoidably introduces. As an interesting exception, DeviceNet can be interconnected at
Search WWH ::




Custom Search