Upload
masriza-kurniawan
View
214
Download
0
Embed Size (px)
Citation preview
8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications
1/13
Incorporating the Best of Both Worlds for
Improved Functionality in Industrial Environments
Thanks to their pecu-
liar features, wireless
networks are currently
becoming more and
more attractive for use
in industrial automa-
tion and manufactur-
ing scenarios. However, they cannotbe thought of as a total replacement
for more traditional wired networks
in such environments, at least in the
short/mid term. This means that for
the time being it is worth focusing on
their integration with the existing in-
dustrial wired solutions, in order to
achieve enhanced flexibility, efficien-
cy, and performance for the overall
networked system.
In this article, some considerations
are presented about the way sev-eral well-known industrial networks
(based on both fieldbus and industrial
Ethernet solutions) can be practically
extended with wireless subnetworks
that rely on popular technologies,
such as IEEE 802.11 and 802.15.4. This
results in hybrid networks, which are
able to combine the advantages of
both wired and wireless solutions. Inparticular, advantages and drawbacks
of several interconnection techniques
are highlighted and, depending on the
wired networks specifically taken into
account, some hybrid configurations
that are able to cope in a satisfactory
way with the tight timing require-
ments often imposed by industrial
control systems are suggested.
Overview
Recent years have witnessed the everincreasing adoption of digital com-
munication networks in manufactur-
ing environments. Field networks
(also known as fieldbuses) [1] are
certainly the most popular solution in
those scenarios. For a long time they
have been used at the lowest levels
of factory automation systems (shop
floor), which are often characterized
by severe timing requirements. On
the other hand, Ethernet networks,
which were traditionally employed as
factory backbones in order to handleinformation flows between different
8 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n MARCH 2008 Digital O bject Identifie r 10.1109/MIE.2008.917155 1932-4529/08/$25.00©2008IEEE
8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications
2/13
MARCH 2008 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 9
GIANLUCA CENA,ADRIANO VALENZANO,AND STEFANO VITTURI
plant areas, are now deemed suitable
also for control applications down to
the field level. This is mostly due to
enhancements of the network perfor-
mance, which led to the development
of industrial Ethernet protocols pur-
posely designed to provide real-time
communications [2]. In many cases,
variants of such protocols have been
defined that are able to support iso-
chronous communications as well.
However, the scenario mentionedabove is quickly evolving, and other
types of communication technolo-
gies, namely wireless networks, are
currently widely available at reason-
able prices. Wireless communica-
tions technologies are becoming more
and more pervasive everyday, and
they are changing deeply several as-
pects of human life by enabling new
perspectives and opportunities that
could hardly even be thought of only
a few years ago. This is likely going to
become true for industrial and factoryenvironments, too, where highly auto-
mated production systems can get sig-
nificant benefits from the introduction
of the most advanced wireless com-
munication techniques. Indeed, sev-eral studies have recently proved the
suitability of some of the most popular
wireless solutions for employment in
industrial scenarios as well, including
real-time communications [3].
Adopting wireless communications
in industrial environments is particu-
larly attractive as it allows, in princi-
ple at least, the avoidance of cabling,
which in many applications turns out
to be cumbersome and/or expensive.
However, while several standard solu-
tions and components are commonly
available for wired industrial com-
munications, wireless systems are far
from being considered well settled for
such kinds of applications. In fact, it is
worth pointing out that the straightfor-
ward introduction of highly innovative
solutions in industrial and manufac-
turing systems has never been either
simple or fast. This is due to several
reasons, such as reliability, efficien-
cy, safety, cost, and security, just to
mention a few. As a consequence, the
growth of wireless technologies in in-
dustrial applications is expected to be
noticeably slower than in other areas,
even though they are envisaged to play
a crucial role in many next-generation
industrial and production systems.
A point most experts agree on is
that wireless communications are un-
likely to be able to replace completely
the current wired solutions adoptedin many industrial scenarios, at least
© PHOTODISC & ARTVILLE
8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications
3/13
10 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n MARCH 2008
in the mid term. Indeed, it is worth
noting that in many practical appli-
cations, this is not considered a real
need. Actually, in factory automation
systems there is often the need to
connect a few components to an al-
ready deployed wired communication
system that cannot be reached (eas-
ily and/or reliably) with a cable. The
most common example is a sensor
mounted on a moving/rotating device
that has to be connected to a control-ler located on a wired segment.
This kind of problem may be eas-
ily solved by providing wireless ex-
tensions to existing wired systems.
Resulting configurations are hybrid
networks in which, typically, wireless
segments have limited geographic
extension (some tens of meters) and
connect only a few stations. Moreover,
controllers are usually located on the
wired segment in such networks. This
implies that wireless (sub)networks
will have to coexist with more tradi-
tional wired communication systems
for quite a long time. Thus, the inte-
gration of wireless and wired com-
munications in industrial scenarios
is becoming a crucial issue that has
to be dealt with carefully in order to
achieve efficiency and performance.
This article focuses on the most
relevant aspects concerning the
aforementioned hybrid networks. In
particular, after a general analysis
of hybrid wired/wireless systems,
the ways wireless extensions of both
fieldbuses and real-time Ethernet
(RTE) networks can be effectively
implemented are taken into account.
Then, examples will be provided of
extensions based on some popular
networks. Specifically, we refer to the
well-known Profibus DP [4] and Devi-
ceNet [5] fieldbus networks, as well
as the Ethernet/IP [6] and Profinet IO[7] RTE networks. (In the latest ver-
sion of the Profinet specification, the
acronym IO has been removed. None-
theless, for practical reasons, in this
article we maintain the original nota-
tion.) It is worth noting that many oth-
er interesting solutions actually exist
that could be provided with a wireless
extension. However, as it would have
been practically unfeasible to deal
with all of them, we decided to focus
on a reduced set of networks that are
nevertheless representative of a widerrange of industrial solutions.
On the other hand, we consider
both the IEEE 802.11 wireless lo-
cal area network (WLAN) [8] and
the IEEE 802.15.4 low-rate wireless
personal area network (LR-WPAN)
[9] as possible wireless extensions.
Indeed, 802.11 WLANs have been al -
ready considered in several studies
and tested in practical applications
that demonstrated their suitability
for industrial use [10]–[12]. For such
a reason, most of the examples pro-
vided in this article are based on
that solution. However, it has to be
noted that 802.15.4 LR-WPAN is an
emerging standard for short-range
connectivity, characterized by long
battery lifetime and low cost. Such
features allow one to implement, for
example, sensor networks distribut-
ed over wide geographical areas and
the connection of sensors/actuators
located on mobile equipment.
As a further possible network
candidate for implementing wireless
extensions, it is worth mentioning
Bluetooth [13]. This network, which
was originally designed as a mere
cable replacement system, has pro-
gressively gained widespread use
thanks to its features, and it is now
employed in several areas, including
industrial automation. For example,
in [14] a real -time wireless sensor/ac-tuator system based on Bluetooth is
described. That system, which uses a
modified version of the original me-
dia access control (MAC) protocol,
has been implemented and its com-
ponents are currently available as
commercial products. However, de-
spite its interesting features, due to
the same practical reasons outlined
above for the wired networks (it is ac-tually impossible to consider all the
available solutions here), we are not
discussing Bluetooth in this article.
Relevant Industrial NetworksThe basic operating principles of the
networks we are going to consider in
this article are briefly discussed in the
following sections.
Profibus DP and Profinet IO
Profibus and Profinet are the maincommunication solutions foreseen by
the Profibus and Profinet International
(PI) community for industrial environ-
ments, each of which is, in turn, made
up of several profiles.
Profibus DP is a widespread field-
bus based on a master-slave ap-
proach, implementing data exchange
between controllers (masters) and
field devices such as sensors and
actuators (slaves) at the maximum
speed of 12 Mb/s. (Actually, the Pro-
fibus DP standard specifies a mas-
ter-master communication as well.
Nonetheless, this is typically meant
for the nonreal-time exchange of di-
agnostic and/or parameterization
data. As such, this type of communi-
cation will not be further considered
in this article.) At the data-link layer,
the medium access is granted exclu-
sively to master stations via a token
passing scheme. It is worth mention-
ing, however, that most practical con-
figurations make use of a single mas-
ter (monomaster networks). Slave
devices can only respond when que-
ried by a master. The operation of the
network is based on a polling cycle of
slaves that is repeated continuously
by the master. At each query of a de-
vice, the master provides the slave
with output data and, at the same
time, fetches the input data. Suitable
techniques are also available for thetransmission of acyclic data.
Another issue that should be taken into account
when interconnecting industrial Ethernet networks
and WLANs concerns the mechanisms for broadcast/
multicast traffic confinement.
8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications
4/13
MARCH 2008 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 11
Profinet IO, instead, is an RTE net-
work included in Part 2 of the IEC 61784
International Standard [15]. In par-
ticular, the communication profile CP
3/6 of such a standard refers to both
Profinet IO RT_Class 2 and 3 specifi-
cations, whereas the communication
profiles CP 3/4 and CP 3/5 both are
concerned with Profinet IO RT_Class1. As specified by the standard, some
different types of stations may be con-
nected to the network, with the most
significant of them being I/O control-
lers (e.g., PLCs or industrial PCs) and
I/O devices (sensors and actuators).
Basically, Profinet IO makes use
of a time division multiple access
(TDMA) technique to guarantee fast
and precise access to the transmis-
sion medium. In practice, the traffic
scheduling takes place according tothe cycle shown in Figure 1. The cycle
is divided into four phases. In the first
one (RED) only RT_CLASS 3 traffic
(the most critical) can take place and
over predefined physical paths en-
forced by a special kind of switches
purposely developed for Profinet IO.
In the ORANGE phase, only RT_CLASS
2 frames are exchanged. In this case,
however, physical paths are not de-
fined. The GREEN phase is reserved
to both RT_CLASS 2 and RT_CLASS 1
frames, either cyclic or acyclic. In this
phase (which is the only mandatory
one) access to the physical medium is
regulated by the priority assigned to
the frames, according to IEEE 802.1Q
[16]. Finally, the YELLOW phase is
used for nonreal-time traffic.
Similarly to other RTE networks de-
fined by the IEC 61784 standard, the ap-
plication layer protocol of Profinet IO
is based on the definition of communi-
cation objects that can be exchanged
over the network via communication
relationships established between I/O
controllers and I/O devices.
DeviceNet and Ethernet/IP
DeviceNet and Ethernet/IP (together
with ControlNet and CompoNet) rely
on the well-assessed common indus-
trial protocol (CIP) [17]—formerly
known as the control and informa-
tion protocol—which enables a highdegree of interoperability among
these kinds of networks. Figure 2 de-
picts the protocol stack foreseen by
CIP. Seamless bridging and routing
is supported natively by this proto-
col, which enables parameterization
information and process data to be
easily exchanged in heterogeneous
distributed systems that employ
both fieldbus and industrial Ether-net transmission technologies.
DeviceNet adopts the control-
ler area network (CAN) protocol at
the lower layers of its protocol stack
(physical and data link). Despite the
bus topology and the relatively low
speed (up to 500 kb/s), it is able to
guarantee deterministic behavior
thanks to the bitwise arbitration tech-
nique featured by CAN. This protocol,
in fact, implements a nonpreemp-
tive priority-based communicationsystem, which does not suffer from
destructive collisions and where the
message with the highest priority is
always given precedence. This also
means that network congestion is im-
plicitly prevented.
Instead, Ethernet/IP is conceived
to rely on conventional Ethernet
transmissions. Even though strictly
deterministic operations are not
granted, the Open DeviceNet Vendor
Association (ODVA) (the organization
that is in charge of managing CIP) has
established a set of design rules [18]
that achieve quasi real-time behavior
in Ethernet/IP. Basically, they require
that switched high-speed Ethernet
is adopted (i.e., full duplex 100-Mb/s
equipment) and that unnecessary
network traffic is kept as low as pos-sible (e.g., by means of virtual LANs
(VLANs) to confine multicast traffic
generated as a consequence of pro-
cess data exchanged over I/O connec-
tions according to the producer/con-
sumer model). As long as the load
on the network is (fairly) below the
theoretical available bandwidth, non-
blocking switches guarantee that any
message is eventually delivered to the
intended destination within a period
of time that, because of the high bitrate, is short enough for most control
applications (at least from a practical
point of view).
IEEE 802.11
The IEEE 802.11 family includes sever-
al standard specifications for wireless
local area networking. All devices be-
longing to such a family (also referred
to as WiFi) work in specific bands of
the radio spectrum, centered around
FIGURE 2 – Protocol stack of CIP-based networks.
TCP/UDP
IP
Ethernet
IEEE 802.3
WiFi
IEEE 802.11
DeviceNetConnectionManager
Encapsulation Protocol
CAN
ISO 11898
CIP (Explicit Versus I/O Messaging)
Device Profiles and Application ObjectsUser Layer
Application
Layer
Transport
Layer
Data-Link
and PhysicalLayers
FIGURE 1 – Profinet IO cycle.
Red
RT_Class 3
Orange
RT_Class 2
Green
Class 2/Class 1
Yellow
Nonreal Time
8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications
5/13
12 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n MARCH 2008
either 2.54 GHz (legacy 802.11, 802.11b,802.11g) or 5 GHz (802.11a). Very
high data rates are foreseen in the
802.11 standard, ranging from 11 Mb/s
(802.11b) to 54 Mb/s (802.11g/a). More-
over, they are expected to increase up
to (about) one order of magnitude with
the next-generation devices (802.11n).
The IEEE 802.11 standard specifies
a mandatory distributed coordination
function (DCF) to access the physical
medium, based on the use of a carrier
sense multiple access with collisionavoidance (CSMA/CA) technique. As a
further, nonmandatory, option, 802.11
encompasses also a centralized MAC
protocol [point coordination function
(PCF)]. In this case, the access to the
network is regulated by a specific sta-
tion, namely, the point coordinator
(PC), which grants exclusive access to
any wireless station, thus preventing
collisions (the main cause of nonde-
terminism in WLANs). Although PCF
is not currently supported by the vast
majority of commercial WiFi boards, it
nevertheless represents an interesting
option for industrial applications, at
least from a theoretical point of view.
Finally, it is worth mentioning that
devices complying with the 802.11e
standard also support the concept of
quality of service (QoS) in the form of
traffic prioritization/parameterization.
Such a property is particularly appeal-
ing for industrial applications since it
allows (at least in principle) for faster
delivery of critical messages. In partic-
ular, the 802.11e specification defines
an additional hybrid coordination
function (HCF), which in turn consists
of two distinct mechanisms; namely,
the enhanced distributed channel ac-
cess (EDCA) and the HCF controlled
channel access (HCCA). Despite HCCA
being able to provide a fairly more
deterministic behavior than EDCA,
thanks to the presence of a hybrid co-ordinator (HC) that effectively ensures
contention-free access to the wirelessmedium by allocating stations trans-
mission opportunities (TXOPs), com-
pliant devices are, at the time of writ-
ing, not available yet. EDCA-compliant
equipment, instead, is currently avail-
able off the shelf at (relatively) low
cost. EDCA is noticeably simpler and
cheaper than HCCA, as it basically re-
lies on a distributed approach. Hence,
it will likely be adopted more and more
in several real-world wireless indus-
trial installations.
IEEE 802.15.4
The IEEE 802.15.4 specification deals
with ad-hoc wireless interconnections
of electronic devices within a limited
transmission range (some tens of me-
ters) at low data rates (up to 250 kb/s).
It has been designed in order to target
several application fields ranging, for
example, from home and building au-
tomation to simple cable replacement
and from smart tags to automotive
sensing. Devices of the IEEE 802.15.4
family typically operate in the indus-
trial, scientific, and medical (ISM)
band, centered around 2.4 GHz (actu-
ally, a second band is also available,
depending on the country considered,
but it is not widely adopted since it is
limited to data rates of 20 kb/s).
Two types of MAC protocols are en-
compassed by the standard: a beacon-
enabled MAC protocol, characterized
by the presence of a network coordina-
tor that periodically sends beacons, and
a nonbeacon MAC protocol. Most of the
commercially available devices operate
in beacon-enabled mode. In this mode,
the network coordinator periodically
issues superframes that are divided in
two parts. The first part, called conten-
tion access period (CAP), takes place
immediately after the beacon and is
based on a distributed CSMA/CA mech-
anism for controlling the access to thechannel. After the CAP, there might be a
(optional) contention-free period (CFP),
in which guaranteed time slots (GTSs)
are exclusively allocated to the nodes.
Conversely, in the nonbeacon mode a
pure CSMA/CA protocol is adopted for
channel access control. In this way, a
totally decentralized and asynchronous
MAC is obtained.
Implementationof Hybrid NetworksFrom a general point of view, the in-
terconnection of different communi-
cation networks is achieved through
specific devices called intermediate
systems (ISs) [19]. These devices have
different structure, functionality, and
complexity, depending on the layer
of the open systems connection (OSI)
reference model they operate.
Interconnection at the Physical Layer
The simplest form of ISs are repeaters.
They operate at the physical layer and
are used to interconnect subnetworks
that share the same MAC mechanism.
They are usually adopted for regenerat-
ing electrical signals flowing across dif-
ferent network segments. In Ethernet
networks, for example, they operate
according to the so called 3-R princi-
ple: reshaping, retiming, and retrans-
mitting. In this way, it is possible to face
the problem of signal attenuation over
the cable when the network extension
grows longer. Moreover, they enable an
increase in the number of nodes that
can be networked, which is practically
limited by the current absorbed by de-
vices attached to the bus.
Besides simpler two-ported de-
vices, a special kind of repeater exists
(called a hub) that is provided with
several ports and can be adopted to
achieve star network topologies. Be-
cause of the increased reliability (a
defective cable no longer affects the
whole network operation), hubs are
particularly suitable for deploying
network infrastructures and for the
cabling of buildings. More advanced
versions of repeaters may be some-
times employed to interconnect sub-
networks that rely on different media
(e.g., copper wires and fiber optics)
or signaling techniques (e.g., voltage/current levels).
Highly automated production systems can get
significant benefits from the introduction of the most
advanced wireless communication techniques.
8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications
6/13
MARCH 2008 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 13
As the MAC mechanism that regu-
lates the access to the shared transmis-
sion medium is the same for the whole
network, care has to be taken about the
increased propagation delays when net-
work segments are connected through
repeaters. In many cases, such as Eth-
ernet, CAN, or Profibus networks, this
leads to limitations on the maximumnumber of repeaters that can be insert-
ed between any two nodes.
An interesting example of hybrid
wired/wireless interconnection car-
ried out at the lowest layer of the pro-
tocol stack is provided in [20]. In that
case, the authors refer to a hybrid ar-
chitecture between Profibus and Ra-
dio Fieldbus [10]. Both networks use
the same data-link layer protocol—
specifically, the fieldbus data link (FDL)
defined by Profibus—but have differentphysical layer protocols. Indeed, Profi-
bus is based on the well-known RS-
485 standard whereas Radio Fieldbus
uses a direct spread spectrum (DSS)
technique similar to the one adopted
in 802.11 WLANs. However, it is worth
noting that pure repeaters are unusual
in real-life hybrid wired/wireless net-
works since the resulting physical com-
munication support in most practical
cases is not seen as a (sufficiently) uni-
form medium by the MAC protocol (the
access techniques adopted by wireless
networks are, typically, rather different
from wired solutions).
Interconnection at the
Data-Link Layer
An IS operating at the data-link layer
is called a bridge. Its function is to
transfer frames between systems
that are not (or cannot be) treated
as a uniform communication support
by protocols at the MAC level (e.g.,
switched LANs that are made up ofseveral separate collision domains).
A bridge that is equipped with more
than two ports is commonly referred
to as a switch (this kind of devices
is currently present in almost every
real-life Ethernet installation).
Even though the MAC mechanism
does not need to be the same for all the
subnetworks interconnected through
bridges/switches, the set of communi-
cation services they provide at the data-
link layer should be similar. Limitationson the kind of networks that can be
interconnected concern, for example,
their addressing scheme (which should
be uniform on the whole network) and
the maximum transfer unit (MTU),
which affects the allowed payload size
as fragmentation is not permitted at the
data-link level. When subnetworks with
different MTUs are interconnected, care
has to be taken so that the payload of
the exchanged frames never exceeds a
threshold equal to the minimum among
the supported MTUs.
Figure 3 shows an example of inter-
connection through a bridge for the
hybrid networks considered in this
article. From a practical point of view,
the bridge to be used in hybrid wired/
wireless networks is a device equipped
with two transmitting/receiving inter-
faces (one for each subnetwork) and,
optionally, a protocol converter. A
frame originated from whatever seg-
ment (either the wired network or thewireless extension) is propagated to
the other by the bridge, which receives
the frame, converts it in the suitable
(target) format, and then retransmits
it. Access points (APs) are a very popu-
lar example of a bridge for hybrid net-
works. APs are used both to enable
communication in an infrastructure
WiFi network [also known as a basic
service set (BSS)] and to interconnect
it to an existing Ethernet backbone
(portal function).
Interconnection at Higher Layers
For ISs working at the network layer or
above, the generic term of gateway is
often adopted. A gateway is responsi-
ble for transferring protocol data units
(PDUs), as well as generic streams of
information and application services
between the application processes
of the interconnected systems, by
performing the required protocol
translations. From a general point of
view, there is no practical restriction
on the kinds of networks that can be
interconnected through gateways.
FIGURE 3 – Interconnection via a bridge.
Data-Link Protocol Converter
Wired
Network
WirelessExtension
Bridge
(Access Point)
Physical
Data Link
Network
Transport
…
Application
Application
Program
Physical
Data Link FrameFrame
Transceivers Physical
Data Link
Network
Transport
…
Application
Application
Program
Physical
Data Link
8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications
7/13
On the other hand, gateways are usu-
ally quite complex, expensive devices,
and the performance they achieve is
somehow lower than bridges (higher
latencies have to be expected).
ISs that operate specifically at the
network layer are known as routers.
At this level, a uniform addressing
scheme and protocol are used [i.e., theinternet protocol (IP)], which ensure
worldwide connectivity regardless of
the physical medium, MAC mecha-
nism, and data-link services of the in-
terconnected subnetworks. However,
we are not directly interested in them
since most industrial networks are de-
ployed as local networks.
When the interconnection takes
place at the application layer (conver-
sion of high-level services), the term
proxy is sometimes adopted. Indeed,a proxy is more than an application-
layer gateway. It usually represents
parts of the network as if they were a
single node, possibly hiding the under-
lying structure for security or perfor-
mance reasons. For instance, proxies
are used in fieldbus/IP connections
to represent legacy fieldbus segments
(as in Profinet).
An example of a wireless extension
implemented at the application layer is
shown in Figure 4. As can be seen, the
gateway incorporates two interface
boards fully compliant with the over-
all protocol stacks of the subnetworks
they are connected to, and a protocol
converter, usually implemented as a
software application.
General Issues Concerning
Wireless Extensions of
Wired Industrial Networks
Although technically feasible, wire-less extensions of industrial networks
to be used at the shop floor (either
fieldbuses or RTE networks) are not
so straightforward. This is basically
due to three main reasons.
First, the transmission support (wire-
less medium) is shared among all the
nodes. Even operating at the maximum
allowable speed (e.g., 54 Mb/s for cur-
rently available 802.11a/g/e networks),
this may result in a low per-station net
throughput compared to that of wirednetworks (especially switched Ethernet)
when the number of connected devices
grows higher. Furthermore, the non-
negligible overheads introduced by the
communication protocol (larger proto-
col control fields, acknowledgement and
reservation mechanisms, no provision
for full-duplex operations, etc.) have
to be considered as well. For example,
the minimum time taken to exchange
reliably 8 B of user data over a WLAN (54
Mb/s, no RTS/CTS, no TCP/IP encapsu-
lation, ad-hoc network mode) including
interframe spaces (as they effectively
waste network bandwidth) is about 100
µs. Such a value is only slightly shorter
than the transmission time over a CAN
network operating at 1 Mb/s.
Second, random access techniques
(e.g., CSMA/CA) are often employed
by wireless networks. This means
that, on the one hand, unpredictable
(and unbounded) transmission delaysmight occur (because of the occur-
rence of repeated collisions) while,
on the other hand, network conges-
tions could be experienced, and this
is surely the worst aspect. In other
words, when the offered load exceeds
a given threshold (even for a limited
time), a condition may likely arise be-
cause of positive feedback so that the
effective net throughput decreases as
the load increases. This means that
the network may become temporarilyunavailable to carry out timely data
exchanges, which is not compatible
with proper operation of distributed
control systems. Moreover, even in the
case of lightly loaded networks, non-
negligible jitters may affect the trans-
mission unless some form of prioritiza-
tion scheme is suitably adopted.
Third, and last, wireless chan-
nels are much more error prone than
wired cabling [21], and this is a seri-
ous drawback when they are used
in industrial environments, which
are usually affected by nonnegligible
FIGURE 4 – Interconnection via a gateway.
Application Protocol Converter
WiredNetwork
WirelessExtension
Gateway
Physical
Data Link
Network
Transport
…
Application
ApplicationProgram
Transceivers Physical
Data Link
Network
Transport
…
Application
ApplicationProgram
Physical
Data Link
Network
Transport
…
Application Services
Physical
Data Link
Network
Transport
…
Application
Controllers
TCP/UDPIP
14 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n MARCH 2008
8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications
8/13
electromagnetic interferences. Besides
causing higher communication laten-
cies and jitters, transmission errors
also directly affect the network reliabil-
ity and, consequently, the robustness
of the overall system. Unless acknowl-
edged transmission schemes are ad-
opted (which, incidentally, are not pos-
sible when broadcast and producer/consumer-like multicast traffic are
taken into account), there is a nonneg-
ligible chance that messages sent over
the air never reach the intended des-
tination. This may also cause consis-
tency problems; i.e., when a multicast
message is received only by a part of
the addressed devices.
Each one of the three drawbacks
mentioned above can be tackled (at
least partially) by means of already
existing or soon to be available tech-nologies. In particular, the throughput
problem could be somehow lessened
by the upcoming 802.11n specification,
which is based on the multiple-input
multiple-output (MIMO) technology
and is theoretically able to provide
a big leap (about one order of mag-
nitude) in the network throughput. A
more reasonable (and viable) choice,
however, could be the use of several
(smaller) separate wireless subnet-
works (e.g., WLANs), interconnected
by means of a wired backbone in or-
der to limit the packet rate on each
one of them. Keeping the size of each
wireless subnetwork small also helps
in operating it at higher speeds (be-
cause of the automatic rate adaptation
mechanism featured by most APs and
WLAN adapters).
The second problem (determin-
ism) can be dealt with through the
adoption of specific medium access
techniques; e.g., PCF in the case of
IEEE 802.11. Unfortunately, PCF is sel-
dom implemented in commercially
available APs. Variants of PCF, such
as the iPCF mechanism introduced by
Siemens [22], have the big drawback of
being proprietary solutions, and hence
compatibility and interoperability can
hardly be ensured. Alternatively, the
new prioritization features offered
by the 802.11e standard (already sup-
ported by several WLAN adapters cur-rently available off the shelf) could be
exploited [23]. While not guaranteeing
strict determinism, such a technology
(originally developed for multimedia
traffic) is able to provide significant
improvements that might often be
enough for many industrial systems.
For example, it is possible to ensure
quasi-real-time behavior by assign-
ing higher priorities to the messagescharacterized by tight timing/safety
constraints. Also TDMA techniques
may be employed to solve the deter-
minism problem. In such a direction,
for example, the guaranteed time slots
provided by IEEE 802.15.4 represent
an interesting opportunity.
The third problem (robustness) can
be faced in several ways. Whenever
possible, a proper placement of anten-
nas is envisaged, optionally by exploit-
ing antenna diversity. In the case thatthis is not enough, leaky wave anten-
nas [24] can be used to ensure reliable
communication over radio links. The
drawback in this case is the need to
deploy the leaky cable infrastructure,
which makes it a nonuniversal solu-
tion. As an alternative, if true mobility
is required, devices operating in the
5-GHz band (802.11a) can be adopted
as a satisfactory choice [21]. In this
way, in fact, interferences with other
devices (mobile phones, Bluetooth-
enabled equipment, notebooks with
wireless connections, etc.) operating
in the standard (and already jammed)
2.4-GHz ISM band are avoided.
IEEE 802.11-BasedExtensions: FieldbusesTypically, the transmission protocols
adopted by fieldbuses are noticeably
different from those employed bywireless networks at all levels of the
communication stack. For example,
random access techniques typical of
WLANs are not employed by any field-
bus network to the best of our knowl-
edge. Other problems may arise that
are related to either the frame pay-
load, which in fieldbuses is typically
very small, or the addressing scheme.
As a consequence, wireless exten-
sions of fieldbuses have to be imple-
mented mainly at the applicationlayer; i.e., through gateways. However,
some remarkable exceptions exist.
DeviceNet, for instance, provides in-
teroperability with all the networks
based on the CIP protocol thanks to
some interesting routing techniques
that allow, in principle, implementing
extensions at a lower level (i.e., through
direct routing of CIP messages).
Extension of Profibus DP
Figure 5 shows that the gateway
needed to extend Profibus DP can be
FIGURE 5 – Gateway with proxy functionality.
DPProto-
col
Profibus DP
IEEE
802.11
Gateway (Profibus DP Master Station)
GatewayCode
InputBuffers
WirelessProtocol
OutputBuffers
MARCH 2008 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 15
8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications
9/13
implemented directly on a Profibus DP
master station. An 802.11 board has to
be installed on the master as well, and
suitable code has to be developed for
this particular implementation in or-
der to enable the exchange of data be-
tween the two segments. The wireless
nodes implementing the extension are
organized in a basic service set (BSS)
which, as specified in the IEEE 802.11
standard, is the basic building block
of a WLAN. A similar solution hasbeen proposed in [11] for the former
version of Profibus; namely, Profibus
FMS. In that paper, some useful results
derived from a set of practical experi-
ments are provided. In particular, the
stations of the BSS, which periodically
exchange 40 B, are handled via a vir-
tual polling algorithm with a resulting
cycle time of 5 ms.
In order to limit the effects of the
delays that are unavoidably introduced
by the gateway, the use of a proxy is
recommended. The proxy hosts a pro-
cess image (decoupled from the wire-
less segments) that can be accessed
from the wired side at any time, with-
out timing restrictions introduced by
the wireless communication protocol.
This is accomplished, as shown in
Figure 5, by means of a set of I/O buf-
fers. Stations on the wireless segment
access these buffers in order to store
the input data acquired from the con-
trolled system. In the same way, output
data written by the proxy into the out-
put buffers are subsequently retrieved
by the wireless stations.
The proxy code is responsible for
interfacing the Profibus DP protocol
to the input/output buffers (it is worth
noting that buffers and data caching,though reasonable for a proxy, from a
general viewpoint are not sufficient). In
detail, when a data exchange requests
that carries output data is issued over
the DP protocol, the proxy code ex-
tracts data from the DP protocol data
unit, writes them into the output buf-
fers, and then generates the acknowl-
edgment for the DP protocol. At the
same time, input data are taken from
the input buffers and returned to the
requester through the DP protocol.
Note that the above technique
does not impose any restriction on
the protocol(s) actually used on the
wireless extension (e.g., as already
mentioned, a virtual polling algorithm
is used in [11]), as data exchanges take
place via I/O buffers.
Extension of DeviceNet
DeviceNet was designed bearing in
mind the option of having several sub-
networks interconnected by means of
routers. Such a feature, besides making
the interconnection with other ODVA
networks (e.g., ControlNet and Ether-
net/IP) simpler, turns out to be very
helpful when implementing wirelessextensions. Routing in heterogeneous
CIP networks is achieved by means of
so-called port segments, which are
added to messages and explicitly de-
scribe the route they should follow
(this is often referred to as source
routing). Such a route is specified by
means of a list of items. Each item, in
turn, describes a hop by means of the
output port of the router to be used in
forwarding the message and the ad-
dress of the intended destination inthe next subnetwork (either the target
node or another router). As the frame
travels along its route, the port seg-
ment is shortened by routers, as each
one of them removes the information
concerning the hop it has processed.
Obviously, the routing process takes
some time, and, hence, response times
over the interconnected network grow
longer. This aspect has to be taken
into account carefully when demand-
ing real-time applications have to be
designed (e.g., it might be necessary
to relax timing constraints).
Using WLANs together with con-
ventional DeviceNet devices can be
accomplished in several ways. The
first, and simpler, solution is to rely
on a DeviceNet to Ethernet/IP router
that, in turn, is connected to a conven-
tional AP (see Figure 6). In this case,
no new hardware component has to
be developed. However, this solution
causes each message to traverse (at
least) two intermediate devices before
reaching its target node (e.g., the rout-
er and the AP), and this introduces ad-
ditional delays.
A second and more sophisticated
solution requires the modification of
existing DeviceNet routers so as to
include an 802.11 port, as shown in
Figure 7 (this should not be a dif ficult
task for manufacturers of DeviceNet
products). In this case, the routeris completely aware of the exactFIGURE 6 – Extension of DeviceNet via a CIP router and an AP.
IEEE802.11
RequestingDevice
DeviceNet toEthernet/IP
RouterAP
TargetDevice
Ethernet/IPDeviceNet
16 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n MARCH 2008
The integration of wireless and wired
communications in industrial scenarios is becoming
a crucial issue that has to be dealt with carefully in
order to achieve efficiency and performance.
8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications
10/13
requirements of each CIP connection,
and, hence, it can select the most suit-
able QoS when forwarding messages
over the radio channel (provided
that a QoS-enabled network, such as
802.11e, is adopted), thus providing
better real-time behavior.
It is worth noting that currently
some devices are actually availableoff the shelf that can be used to intro-
duce wireless extensions to DeviceNet
networks. For instance, [25] describes
a solution that relies on the routing of
messages for carrying out information
exchanges over explicit connections.
Such a solution foresees a wireless
master (implemented as a DeviceNet
slave) connected to the primary
DeviceNet bus, and one or more wire-
less slaves (which are seen as virtual
DeviceNet masters), each one con-necting a different DeviceNet remote
bus. To improve communication ef-
ficiency, process data collected by
wireless slaves from each remote bus
can be provided to the master as a sin-
gle process image. Unfortunately, solu-
tions like this are mostly based on pro-
prietary communication technologies,
and, hence, they cannot be considered
as universal proposals.
IEEE 802.11-Based Extensions:Real-Time Ethernet NetworksDespite the availability of both hard-
ware components and protocols, the
implementation of wireless extensions
to RTE networks is not immediate. In-
deed, interoperability between Eth-
ernet and WLANs is always ensured
by using inexpensive off-the-shelf
devices (i.e., APs), along with some
commonly available protocols. As an
example, the IEEE 802.1D bridging
protocol [26] allows for interconnec-
tions at the data-link layer; however,
such a solution, which has good effi-
ciency, is sometimes difficult to imple-
ment since it relies on the availability
of IEEE 802.2 logical link control (LLC)
services, which are not always explic-
itly accessible on Ethernet and 802.11
off-the-shelf components.
A more straightforward intercon-
nection technique can be obtained via
the TCP/IP protocol suite but, unfor-tunately, it is unsuitable for achieving
real-time behavior. For this reason, in
some cases the User Datagram Proto-
col (UDP) protocol [27] is preferred.
UDP, in fact, has lower overheads than
TCP and offers simpler access to com-
munication thanks to its unacknowl-
edged transmission scheme (which
lacks the sliding window mechanism).
In this case, however, the weakpoint is found in the access protocols
adopted by RTE networks, which often
are not completely compliant with the
original Ethernet specifications. For
example, Ethernet Powerlink (EPL)
[28], which actually relies on standard
Ethernet controllers, adopts a protocol
based on a fast and precise periodic
polling carried out on (wired) nodes
that ensure rapid operation (cycle time
under 200 µs) and ultra-low jitter (be-
low 1 µs). Unfortunately, this does notallow for the integration of wireless
devices, due to the unavoidable uncer-
tainty of communication times over
radio channels (because of interfer-
ences and electromagnetic noise) that
impairs determinism unacceptably.
Extension of Profinet IO
The extension of Profinet IO has to
face all the problems discussed in the
previous sections. Indeed, it is not
possible to implement an extension at
the data-link layer, since the CSMA/CA
technique employed by IEEE 802.11
cannot cope with the very tight time
schedule imposed by the TDMA medi-
um access technique used by Profinet
IO. Consequently, the extension may
only be implemented at the applica-tion layer, via a gateway, in a way simi-
lar to that described for Profibus DP.
There are, however, two alterna-
tive options for carrying out such
a task. When real-time behavior is
not required, data exchange with
the wireless nodes may simply take
place in the nonreal-time period of
the Profinet IO cycle (the YELLOW
phase shown in Figure 1). The second
option is more appealing, since it en-
ables preserving real-time properties,and is based on the use of the PCF. As
shown in Figure 8, an AP implement-
ing the PCF technique can be used as a
bridge. With such a solution, wireless
stations can be included in the Profi-
net IO cycle, too, since the AP is able
to assign them specific time slots that
provide contention-free (and, hence,
deterministic) access to the wireless
medium. Specific actions should be
FIGURE 7 – Extension of DeviceNet via a WLAN-enabled CIP router.
IEEE802.11
DeviceNet
to WLANRouter
DeviceNet
TargetDevice
Requesting
Device
MARCH 2008 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 17
FIGURE 8 – Extension of Profinet IO via a bridge.
ProfinetIO
Interface
IEEE802.11
APwith
PCFProfinet IO
Bridge
8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications
11/13
taken in this case so as to improve net-
work reliability as well (e.g., by means
of leaky cables).
An example of an application based
on this technique is described in [29]
(actually, the iPCF technique men-
tioned earlier in this article is used).
In [29], 21 Profinet IO devices are lo-
cated on a wireless segment, whereasthe Profinet IO controller relies on
wired connections. The bridge is a
commercial product [22] implement-
ing iPCF.
Extension of Ethernet/IP
As long as Ethernet/IP networks are
taken into account, there is no theo-
retical need for any change to adapt
the CIP protocol to 802.11 networks.
In fact, APs can be used that trans-
parently forward each message tothe intended destination by means of
its Ethernet address (which, in turn,
is derived from the IP address used
at the application level), as shown in
Figure 9. While this is certainly the
most appealing (and inexpensive)
solution, it might lead to suboptimal
results when real-time process data
have to be exchanged. This is because
in the existing conventional 802.11b/g
WLANs, priorities cannot be enforced
for process data higher than those
for background traffic, unless special
techniques, such as those provided by
802.11e, are adopted.
In the latter case, however, existing
implementations of CIP are likely to
be modified in order to map the tim-
ing constraints of each message (I/O
versus explicit connection, expected
packet rate, and so on), which are
known at the application level, onto
the most suitable QoS as provided by
the underlying communication sys-
tem. From this point of view, Ethernet
is not the same as 802.11e WLANs. In
fact, IEEE 802.1Q [16] enables specify-
ing up to eight traffic classes to encode
frame priority in switched Ethernet,
whereas 802.11e foresees four differ-
ent access categories (ACs) to provide
traffic prioritization.
It is worth noting that developingWLAN-enabled Ethernet/IP devices,
such as the target node on the right
side in Figure 9, is not really a difficult
task. The advantage of adopting this
kind of solution is that the device can
exploit the knowledge about the timing
requirements of the CIP connection to
select the most suitable QoS. A viable
choice could be, for example, to map
I/O connections with tight timing re-
quirements (i.e., high expected packet
rate) on voice-grade (AC_VO) traffic,whereas those having less severe con-
straints on the transmission times can
be mapped on video-grade (AC_VI)
transmissions. Finally, explicit con-
nections devoted to parameterization
can rely on either best-effort (AC_BE)
or background (AC_BK) traffic.
In the case where conventional
APs are used to interconnect wired
Ethernet/IP segments with wireless
extensions, exploiting 802.11e QoS
becomes more difficult. Indeed, it is
impossible for a conventional AP to
determine the priority of each frame,
since it is defined at the application
layer, whereas the AP operates at the
data-link layer. A possible solution is
to rely on APs that are able to map
802.1Q traffic classes directly onto
IEEE 802.11e ACs (and vice versa).
Besides traffic prioritization, an-
other issue that should be taken into
account properly when interconnect-
ing industrial Ethernet networks and
WLANs concerns the mechanisms
for broadcast/multicast traffic con-
finement (process data are usually
exchanged according to the producer/
consumer paradigm). In wired net-
works such as Ethernet/IP, this is dealt
with by means of VLANs. Although
this mechanism is not available in
802.11 wireless networks to reducethe amount of multicast traffic, some
devices are currently available off the
shelf that can map VLANs to different
service set identifiers (SSIDs) [30].
Such a feature is quite interesting,
as it can be used to ease the integra-
tion of WLAN extensions to existing
Ethernet/IP networks.
IEEE 802.15.4-Based ExtensionsIn analogy with the networks defined
by the IEEE 802 committee(s), the IEEE802.15.4 specification only refers to the
lower two layers of the communication
stack and does not specify any type of
upper-layer protocol. Thus, in order to
grant access to 802.15.4 networks by
the higher layers, two options are rec-
ommended by the standard:
using LLC type 1 services [31]
accessing MAC services directly.
Both techniques can be employed
profitably, even if it is worth men-
tioning that LLC services are seldom
made available by 802.15.4 board
manufacturers.
Due to the limited transmission
speed of IEEE 802.15.4, the resulting
hybrid networks are not generally
able to provide (very) fast communica-
tions. On the other hand, the 802.15.4
protocol has good efficiency, especial-
ly when compared to 802.11. Finally,
the guaranteed time slots made avail-
able in the beacon-enabled mode al-
low a co-ordered (e.g., deterministic)
access scheme to the shared medium
by wireless nodes, with a consequent
reduction of the jitters that typically
affect pure CSMA/CA protocols.
Extension of Fieldbuses
The use of IEEE 802.15.4 for implement-
ing wireless extensions of fieldbuses
basically presents the same problems
already discussed for IEEE 802.11-
based extensions. In particular, theremarkable differences between the
■
■
FIGURE 9 – Extension of Ethernet/IP via an AP.
IEEE802.11eAP
Ethernet/IP
Target
DeviceRequesting
Device
18 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n MARCH 2008
8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications
12/13
MAC protocols of the two kinds of
networks do not practically allow for
the interconnection at the lower lay-
ers. Thus, from the above consider-
ations it follows that fieldbus exten-
sions based on 802.15.4 networks can
only be achieved through a gateway
that translates the services foreseen
by the application layer of the field-bus to calls to 802.15.4 services. The
gateway is typically implemented as
a station that embeds the interface to
the wired fieldbus and, at the same
time, acts as network coordinator for
the 802.15.4 system.
Similarly to the case of the extension
of Profibus DP through IEEE 802.11, also
in this case there are no restrictions on
the protocol(s) actually employed over
the wireless extension. Indeed, the gate-
way may either use the 802.15.4 data-linklayer services (LLC or MAC) directly or,
alternatively, it may rely on the func-
tions provided by a proprietary proto-
col explicitly defined for managing data
exchanges over the wireless extension.
Once again, note that significant ben-
efits may be obtained by the use of
the guaranteed time slots. As an ex-
ample, the virtual polling algorithm
described in [11] for 802.11-based ex-
tensions does not need to be imple-
mented from scratch for IEEE 802.15.4
since, in practice, such a mecha-
nism is natively provided by the
beacon-enabled mode of the access
technique.
Extension of Real-Time Ethernet
Concerning RTE networks, the avail-
ability of the 802.15.4 LLC protocol
could enable, in theory, the imple-
mentation of extensions right at the
data-link layer, since most RTE net-
works provide access to such a layer
as well. However, it has to be con-
sidered that LLC type 1 services are
nonconfirmed, connectionless ser-
vices. Such a feature may represent
a serious drawback, which could lead
to a decrease of the overall system
performance due to the nonnegligible
probability of errors affecting com-
munications in the wireless segment.
In fact, since 802.15.4 does not imple-
ment frame retransmission at theMAC level, a (possible) corruption of
a frame cannot be recovered by the
LLC type 1 services (because they are
unconfirmed) with the consequent
definitive loss of the related protocol
data unit. This means that also in this
case an effective extension can only
take place via a gateway.
Finally, it is worth mentioning that
ZigBee [32] offers a complete proto-
col stack based on IEEE 802.15.4 and,
obviously, represents an interesting
opportunity for implementing hybridnetworks when the wired segment
consists of either a fieldbus or an
RTE network. In particular, it is inter-
esting to notice that ZigBee enables
connectivity with whatever type of
network based on the IP protocol
by means of the purposely defined
ZigBee expansion devices (ZEDs).
As a consequence, it is possible (at
least in principle) to interface easily
with some RTE networks (basically,
all those that allow for TCP/IP com-
munication, such as, for example,
Ethernet/IP and Profinet IO) via a
conventional IP router.
ConclusionIt is envisaged that network configu-
rations resulting from wireless exten-
sions of conventional (wired) indus-
trial networks will be adopted more
and more in the near future, thanks to
the availability of wireless technolo-
gies and devices able to cope with in-
dustrial communication requirements
properly. Concerning wired networks,
the analysis presented above focused
on two popular fieldbuses (Profibus
DP and DeviceNet) and two RTE net-
works (Profinet IO and Ethernet/IP),
since they are based on different
protocols. In the same way, both the
IEEE 802.11 family of WLAN standards
and IEEE 802.15.4 wireless sensor net-
works were taken into account as wire-less extensions, as they are two of the
most promising technologies for in-
dustrial and control applications, and
many devices are already available off
the shelf at (relatively) low cost.
As pointed out in the article, the
extension of Profibus DP and, in gen-
eral, of almost all fieldbuses, can
typically take place at the applica-
tion layer. While providing greater
flexibility, this may worsen the over-
all performance, due to the delays
gateways unavoidably introduce. Asan interesting exception, DeviceNet
can be interconnected at a lower
layer via CIP routers. This means
that in hybrid networks based on
DeviceNet all devices can be seen
(and accessed) as conventional CIP
nodes, whereas in the case where a
gateway/proxy is adopted (as hap-
pens in Profibus DP) wireless nodes
are no longer effectively part of the
Profibus network.
When real-time (industrial) Eth-
ernet networks have to be provided
with a wireless extension, more
alternatives are possible, in prin-
ciple, including interconnection
at the data-link level. However, as
these networks often rely on pecu-
liar protocols to ensure predictable
communications over Ethernet,
the integration with WLANs is not
straightforward. As a consequence,
a loss of performance/determinism
in hybrid networks may occur also
in this case. Moreover, when 802.11
is selected for the wireless exten-
sion, the native randomness of the
DCF medium access technique has
to be taken into account carefully
in the design of the hybrid network,
as it can give rise to additional (and
unwanted) delays. Significant im-
provements in this direction could
be achieved by using deterministic
techniques such as, for example, PCFin WLANs (which, however, is not so
The IEEE 802.15.4 specification deals with ad-hoc
wireless interconnections of electronic devices within
a limited transmission range (some tens of meters)
at low data rates (up to 250 kb/s).
MARCH 2008 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 19
8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications
13/13
frequently available in real devices)
or guaranteed time slots in 802.15.4
networks (which, however, suffer
from a noticeably lower bit rate).
Finally, an interesting option for
achieving quasi-real-time communica-
tions is also offered by the IEEE 802.11e
standard, which supports the concept
of QoS. Indeed, it has been shownthat, as an example, traffic prioritiza-
tion could be used to deal with differ-
ent types of messages (and, hence,
of timing requirements) defined and
handled by the CIP protocol, so as to
transparently enable control applica-
tions to meet real-time constraints
even when hybrid interconnections
are adopted.
Biographies
Gianluca Cena is director of researchwith the Istituto di Elettronica e di
Ingegneria dell’Informazione e delle
Telecomunicazioni of the Italian Na-
tional Research Council (IEIIT-CNR),
where he is engaged in activities con-
cerning communications in manufac-
turing and automotive environments.
He is the author of many technical
papers in the area of computer com-
munications. His current research
interests include industrial commu-
nication systems and protocols and,
in particular, real-time networks. He
is also active in the international sci-
entific community operating on these
subjects, and he served as program
cochairman for the sixth and seventh
editions of the IEEE Workshop on Fac-
tory Communication Systems.
Adriano Valenzano is director of
research with the Istituto di Elettron-
ica e di Ingegneria dell’Informazione
e delle Telecomunicazioni of the Ital-
ian National Research Council (IEIIT-
CNR), where he is responsible for re-
search on computer communications
and formal methods for the analysis
of security-critical systems. He is
the author/coauthor of about 200 pa-
pers published in international jour-
nals, books, and conferences in the
area of computer engineering. He is
an associate editor of the IEEE Trans-
actions on Industrial Informatics. He
has also served as a general cochair-man for the Sixth IEEE International
Workshop on Factory Communica-
tion Systems. His research interests
concern computer communications
(in particular, industrial communi-
cations) and the formal analysis of
security-critical systems.
Stefano Vitturi received the Lau-
rea degree (summa cum laude) in
electronics engineering from Univer-sity of Padova, Padova, Italy, in 1984.
He has been a senior researcher with
the Istituto di Elettronica e di Ingeg-
neria dell’Informazione e delle Tele-
comunicazioni of the Italian National
Research Council (IEIIT-CNR) since
January 2002. His research interests
include industrial real-time communi-
cation networks (wired and wireless)
and implementation and performance
analysis of devices conforming to the
most popular industrial communica-tion protocols. In the context of these
activities, he is an expert of the IEC
SC 65 Standardization Subcommittee,
and he has been the scientific respon-
sible of the Italian Profibus Compe-
tence Center.
References[1] J.P. Thomesse, “Fieldbus technology in indus-
trial automation,” Proc . IEEE , vol. 93, no. 6, pp.1073–1101, June 2005.
[2] J.D. Decotignie, “Ethernet-based real-time and
industrial communications,” Proc . IEEE , vol.93, no. 6, pp. 1102–1117, June 2005.[3] A. Willig, K. Matheus, and A. Wolisz, “Wireless
technology in industrial networks,” Proc. IEEE ,vol. 93, no. 6, pp. 1130–1150, June 2005.
[4] Prof ibus-DP Standard, Translation of the German National Standard DIN 19245 Part 3 , DeutschesInstitut fuer Normung, 1994.
[5] Low-Voltage Switchgear and Controlgear— Controller-Device Interfaces (CDIs)—Part 3: DeviceNet , IEC Standard 62026-3, July 2000.
[6] Open DeviceNet Vendor Association, EtherNet/ IP Adaptation of CIP, Edition 1.3 (CIP NetworksLibrary, Vol. 2). Ann Arbor, MI: ODVA, 2007.
[7] PROFIBUS International, “Application layerprotocol, application layer services for decen-tralized periphery and distributed automa-tion, specification for Profinet,” ver. 2.2, Oct.
2007.[8] IEEE Standards for Information Technology—
Telecommunications and Information Exchange Between Systems—Local and Metropolitan Area Networks—Specific Requirements—Par t11 Wireless LAN Medium Access Control (MAC)and Physical Layer (PHY) Specifications, IEEEStandard 802.11-2007, June 2007.
[9] IEEE Standard for Information Technology— Telecommunications and information exchangebetween systems—Local and metropolitanarea networks—Specific requirements—Part15.4: Wireless Medium Access Control (MAC)and Physical Layer (PHY) Specifications for Low—Rate Wireless Personal Area Networks(WPANs), IEEE Standard 802.15, Sept. 2003.
[10] L. Rauchhaupt, “System and device architec-ture of a radio based fieldbus—The RF Field-
bus system,” in Proc . IEEE WFCS 2002 , Vast-eras, Sweden, Sept. 2002.
[11] S. Lee, K.C. Lee, M.H. Lee, and F. Harashima,“Integration of mobile vehicles for automatedmaterial handling using Profibus and IEEE802.11 networks,” IEEE Trans. Ind. Electron.,vol. 49, no. 3, pp. 693–701, June 2002.
[12] A. Willig, M. Kubisch, C. Hoene, and A. Wolisz,“Measurements of a wireless link in an industri-al environment using an IEEE 802.11-compliantphysical layer,” IEEE Trans. Ind. Electron., vol.49, no. 6, pp. 1265–1282, Dec. 2002.
[13] Bluetooth Special Interest Group, [Online].Available: www.bluetooth.com
[14] D. Dzung, J. Endresen, C. Apneseth, and J.-E.Frey, “Design and implementation of a real-time wireless sensor/actuator communicationsystem,” in Proc. IEEE ETFA 2005 , Catania,Italy, pp. 433–442, Sept. 2005.
[15] Indust rial Communication Networks—Part 2: Additional Fieldbus Prof iles for Real-Time Net- works Based on ISO/IEC 8802-3 , IEC Standard61784-2, Dec. 2007.
[16] IEEE Standard for Local and Met ropolitan Area Networks Vir tual Bridged Local Area Networks ,IEEE Standard 802.1Q-2005, 2006.
[17] Open DeviceNet Vendor Association, Common Indust rial Protocol (CIP) Specif ication, Edition3.2 (CIP Networks Library, Vol. 1). Ann Arbor,MI: ODVA, 2007.
[18] Open DeviceNet Vendor Association, Network
Infrastructure for EtherNet/ IP: Introduction andConsiderations (publication no. PUB00035R0).[Online]. Available: http://www.odva.org/Por-tals/0/Library/Publications_Numbered/PU-B00035R0_Infrastructure_Guide.pdf
[19] F. Halsall, Data Communications, Computer Networks and Open Systems. Reading , MA:Addison Wesley, 1996.
[20] C. Koulamas, S. Koubias, and G. Papadopoulos,“Using cut-through forwarding to retain thereal-time properties of Profibus over hybridwired/wireless architectures,” IEEE Trans. Ind. Elect ron., vol. 51, no. 6, pp. 1208–1217, Dec.2004.
[21] D. Brevi, D. Mazzocchi, R. Scopigno, A. Boniven-to, R. Calcagno, and F. Rusinà, “A methodologyfor the analysis of 802.11a links for safety-critical
industrial communications,” in Proc. IEEE WFCS2006 , Torino, Italy, pp. 165–174, June 2006.
[22] Siemens AG, “SCALANCE W788 RR AccessPoint” [Online]. Available: www.automation.siemens.com/net
[23] G. Cena, I. Cibrario Bertolotti, A. Valenzano,and C. Zunino, “Evaluation of response timesin industrial WLANs,” IEEE Trans. Ind. Infor- mat., vol. 3, no. 3, pp. 191–201, Aug. 2007.
[24] G. Baumann, “Controlling the wireless field,” Indust . Wireless Book, vol. 9, no. 3, June 2006.
[25] OMRON, (2002, Sept.) WD30-ME/-SE/-ME01/-SE01 DeviceNet Wireless Units—OperationManual. [Online]. Available: http://www.om-ron.com/
[26] Media Access Control (MAC) Bridges , IEEE Stan-dard 802.1D, June 2004.
[27] User Datagram Protocol , DARPA Standard RFC768, Aug. 1980.
[28] Ethernet Powerlink Standardization Group,“Ethernet Powerlink communication profilespecification,” ver. 2.0, 2003.
[29] G. Santandrea, “A Profinet IO applicationimplemented on wireless LAN,” presented at6th IEEE Int. Workshop on Factory Communica- tion Systems (Industry Day), Torino, Italy, June2006. (Slides available: http://wfcs2006.ieiit.cnr.it/)
[30] 3Com. (2006, June 19). 3Com Wireless 776011a/b/g PoE Access Point User’s Guide. [On-line]. Available: http://www.3com.com/
[31] Logical Link Control (with amendments 3, 6and 7), IEEE Standard 802.2, 1998.
[32] The ZigBee Alliance (2006, Dec.) “ZigBee specifi-
cation,” [Online]. Available: www.zigbee.org/en/spec_download/zigbee_downloads.asp