Communication Systems in Industrial Automation

Control Engineering Practice 15 (2007) 1332–1347
Communication in industrial automation—What is going on?
Peter NeumannÃ
Institut f. Automation und Kommunikation Magdeburg (ifak), Steinfeldstr. 3, 39179 Barleben, Germany
Received 22 March 2005; accepted 2 October 2006
Available online 11 December 2006
Abstract
Fieldbus systems have been successfully introduced into industrial automation. Nowadays, a large community is inventing the usage of
Ethernet-based local communication systems in this domain ensuring the real-time, safe and secure behaviour of these systems. Future
scenarios of geographically distributed production plants or services require the use of heterogeneous networks consisting of local and
wide area, and wired and wireless communication systems operated by different authorities. Thus, behaviour has to be supplemented by
context awareness realised by location-based communication services and context-sensitive applications. This paper will mainly address
the ongoing activities in the field of using heterogeneous networks within the automation domain.
r 2006 Published by Elsevier Ltd.
Keywords: Ethernet; Communication systems; Decentralised control systems; Industry automation; Real-time; Performance
1. Introduction
For the last 20 years a lot of effort has led to the decisive
usage of digital communications in distributed computer
control systems within the factory as well as the process
domain. The proprietary communication systems within
SCADA systems were supplemented and partially dis-
placed by the Fieldbus systems and sensor bus systems. At
the same time, Ethernet won the battle as the most used
communication technology within the office domain
resulting in low component prices caused by the mass
production of these components. For the last five years and
especially nowadays, there is a large community inventing
the usage of Ethernet-based communication systems to be
used in the industrial automation domain, i.e. in the real-
time (RT) and safety-critical world (Alves, Tovar, &
Vasques, 2000; Haertig & Loeser, 2004; Hoang, Jonsson,
Hagstrom, & Kallerdahl, 2002; Thanikesavan & Killat,
2004). Liu (2000), Furrer (2003) and Marshall (2004)
contain an overview regarding the RT aspects. However,
in contrary, Fieldbus systems are the most important
communication systems used in commercial control
installations.
Since there is an economic interest to widely introduce
the Ethernet-based and radio-based technologies, the
inventors have to guarantee that the domain-specific
requirements can be fulfilled.
These requirements are:
Guaranty for RT behaviour: There are different applica-
tions (non-RT applications: diagnosis, maintenance,
commissioning, slow mobile applications; soft RT
applications: processes in manufacturing and process
automation, data acquisition; hard RT applications:
control applications, fast mobile applications, machine
tools; and isochronous hard RT applications: motion
control).
Guaranty for functional safety: This means prote-
ction against hazards caused by incorrect functioning
including communication via heterogeneous networks.
There are several Safety Integrity Levels SIL (IEC,
2000).
Guaranty for security: This means a common security
concept for distributed automation using a heteroge-
neous network with different Security Integrity Levels
(not existent yet).
ARTICLE IN PRESS
www.elsevier.com/locate/conengprac
0967-0661/$ - see front matter r 2006 Published by Elsevier Ltd.
doi:10.1016/j.conengprac.2006.10.004
ÃTel.: +49 39203 81010; fax: +49 39203 81100.
E-mail address: peter.neumann@ifak.eu.

Future scenarios of distributed automation lead to desired
mechanisms for geographically distributed automation
functions due to various reasons:
Centralised supervisory and control of (many) decen-
tralised (small) technological plants.
Remote control, commissioning, parameterisation and
maintenance of distributed automation systems.
To include remote experts or external machine-readable
knowledge for the plant operation and maintenance.
This means that heterogeneous networks, consisting of
local and wide area as well as wired and wireless
communication systems, will play an increasing role.
However, there is not only a need for RT, safe and secure
communication. The desired context awareness leads to the
usage of location-based communication services and
context-sensitive applications. Thus, the functionalities
offered by the entertainment electronics will influence more
and more the complexity of the communications approach
within the automation domain. Since the Fieldbus technol-
ogy has reached a stable phase within industrial automa-
tion, this paper will mainly deal with the ongoing activities
in the field of using Ethernet and heterogeneous networks
including wireless communications.
The following problems have to be solved (Neumann,
2004):
Definition of RT classes and guaranty of suitable
behaviour for non-RT, soft RT, and hard RT applica-
tions.
Usability of wireless communications within the auto-
mation domain.
Functional safety concepts and mechanisms.
Security concepts and mechanisms.
Local awareness within industrial automation.
2. RT behaviour
2.1. RT classes
Within the automation domain the RT requirements are
focused to the response time behaviour of data packets.
Thus, there are three RT classes guaranteeing response time:
Class 1: soft RT (scheduling of data traffic on top of
UDP/TCP): scalable cycle time; used in factory floor
and process automation.
Class 2: hard RT (scheduling of data traffic on top of
MAC): cycle time 1–10 ms. Used for control.
Class 3: isochronous RT (with time/clock synchronisa-
tion and routing with time schedule): cycle time 250 ms to
1 ms; jitter less than 1 ms. Used for motion control.
Additionally, there is a class ‘‘non-RT’’ which has not been
considered here.
2.2. Local industrial communication
Digital communication has been an important driving
force of the computer control systems for the last 25 years.
To realise the access to data in various layers of an
enterprise information system by different users, there is a
need to merge the different digital communication systems
within the plant level, control level, and device level of an
enterprise network. On these different levels, there are
different requirements dictated by the nature and type of
information being exchanged (Jasperneite Neumann,
2001a, 2001b). Network physical size, the number of devices
supported, network speed, response time, frequency of
exchange and payload size are a few of the performance
characteristics used to classify and group specific network
technologies. The RT requirements depend on the type of
messages to be transmitted: meeting deadlines for data
transmission, restricting jitter for audio and video stream
transmission. Otherwise, the offered resources at the various
network levels are different. At the device level, there are
extremely limited resources (hardware, communications),
but at the plant level there are powerful computers allowing
comfortable software and memory consumption.
2.2.1. Fieldbus systems
In particular over the last 15 years, Fieldbus systems have
required a lot of work in the area of definition, specification,
implementation and market dissemination. Nowadays, the
Fieldbus systems are standardised (though unfortunately
not unified) and widely used within the industrial automa-
tion. IEC (2003a, 2003b) contain 10 different Fieldbus
concepts. Seven of these concepts have their own complete
protocol suite (PROFIBUS: Siemens, PNO; Interbus:
Phoenix Contact, Interbus Club; Foundation Fieldbus
H1: Emerson, Fieldbus Foundation; SwiftNet: B.Crowder;
P-Net: Process Data; WorldFIP: Schneider, WorldFIP),
three of them are based on Ethernet functionality (high-
speed Ethernet HSE: Emerson, Fieldbus Foundation;
Ethernet/IP specification (2001): Rockwell, ODVA; PRO-
FINET/CBA: Siemens, PNO). The world-wide leading
positions within the automation domain regarding the
number of installed Fieldbus nodes hold PROFIBUS
(about 14 million nodes) and Interbus (about 7 million
nodes). A good commercial position is being held by the
DeviceNet solution (Rockwell, ODVA), which has not been
part of the IEC 61158 standard. Also the CAN-based
solutions with the Application Layer supported by the
‘‘CAN in Automation’’ association has not been part of
that Fieldbus standard, but widely used in different
application domains. The mentioned Fieldbus systems fulfil
the recent technical requirements of local industrial com-
munications at the field level of an enterprise. Recently,
radio front ends complete the Fieldbus transmission
technology. An example has been realised by the European
project RadioFieldbus (Rauchhaupt, 2002, 2003).
In 2004, the IEC started a New Work Item Proposal to
start the maintenance phase of the Fieldbus standard IEC
ARTICLE IN PRESS
P. Neumann / Control Engineering Practice 15 (2007) 1332–1347 1333

61158 (Edition 4) in 2005. As a result additional Ethernet-
based solutions became part of a Public Available
Specification (IEC, 2004a–2004i); see Table 1. These
solutions spread over all RT classes and will become part
of the Fieldbus standard.
2.2.2. Ethernet-based local RT approaches
2.2.2.1. A short overview. The Local Area Networks
(LAN) based on Ethernet-TCP (UDP)/IP has been standar-
dised and widely introduced in the office domain and also in
the automation domain, using Shared Ethernet as well as
Switched Ethernet (star and tree topology). There are
system-specific limits regarding the RT behaviour, especially
if the solutions use the TCP (UDP)/IP functionality and a
middleware above TCP (UDP)/IP to schedule the (soft) RT
traffic (RT class 1) and the non-RT traffic. (Po¨ schmann
Werner, 2003) compares these approaches. There are many
investigations regarding temporal behaviour related to
Ethernet-TCP/IP-based local networks; see e.g. Pedreiras
and Almeida (2005). They include mainly the response aspect
of data packet transmission, which is very important within
the industrial automation domain. The synchronous video or
audio stream transmission, supported by the infrastructure
of LAN, is of secondary interest. In the industrial automa-
tion application, the data packet transmission with guaran-
teed response time has to have the highest priority.
A lot of research activities deal with a middleware on top
of the MAC layer of Ethernet, scheduling the RT and soft
RT/non-RT traffic, see e.g. Agarwal and Wang (2003),
Alves et al. (2000), Bonaccorsi, Lo Bello, Mirabella,
Neumann, and Po¨ schmann (2003), Caponetto, Lo Bello,
and Mirabella (2003), Carpenzano, Caponetto, Lo Bello,
and Mirabella (2002). Choi, Song, Birch, and Huang
(2000), Dolejs and Hanazalek (2003), Georges, Rondeau,
and Divoux (2002a, 2002b), Jasperneite (2002), Lee and
Lee (2002), Loeser and Haertig (2004), Kweon, Shin, and
Zheng (1999), Song, Koubaa, and Simonot (2002), Wang
and Ravindran (2004), Fan, Wang, and Sun (2002) deal
with the usage of switched Ethernet in the automation
domain (RT class 2). Pedreiras and Almeida (2005) contain
ARTICLE IN PRESS
Table 1
Real-time Ethernet: systems addressed by PAS (IEC, 2004a–2004i)
System Real-time
class
Scheduling of real-time
traffic
Scheduling principle Non-real-time
over
Application
models
Synchronisation
MODBUS
RTPS
1þ On top of UDP/IPv4 RTPS Wire Protocol UDP/IPv4 Publisher/
Subscriber
P-Net on IP 1 Mapping of P-Net
packages into UDP/IP
packages
Comparable to P-Net UDP/IP Client/Server
TCnet 2þ On top of MAC Comparable to token
passing
TCP/IP Publisher/
Subscriber
Vnet 2 On top of MAC Time slot organisation UDP/IP Client/Server
Ethernet IP with
time
synchronisation
3 On top of TCP/IP Common industrial
protocol
TCP/IP Publisher/
Subscriber
IEC 61588 Precision
Clock Synchronisation
Protocol PTP
SERCOS III 3 On top of MAC Time slot organisation MAC Client/Server Ring delay
measurement,
Calculation of
Synchronisation time
during
Communication Phase
0
EtherCAT 3 On top of MAC Time slot organisation UDP/IP Client/Server Clock master
synchronisation by
boundary clock (IEC
61588). Distributed
clock, clock master
within first segment
slave. Measurement of
propagation delays,
corrections
PROFINET 3 On top of MAC Time slot organisation UDP/IP Publisher/
Subscriber
PTP (IEC 61588),
extensions for line
topology
PowerLink 3 On top of MAC Time slot organisation TCP,UDP/IP Publisher/
Subscriber (real-
time data),
Client/Server
(other data)
PTP (IEC 61588)
þ—partial features of the next real-time class.
P. Neumann / Control Engineering Practice 15 (2007) 1332–13471334

a rough overview of the methods and implemented
systems. The investigated RT mechanisms are very
important for synchronous data transmission in the
Motion Control area (RT class 3). Examples of this
category are described in Section 2.2.2.3. Additionally, the
1394automation e.V. specified an approach based on IEEE
1394 transmission technology (Gorka, 2005), also offering
a good dynamic behaviour for motion control (class 3).
Investigations have shown that at present the switched
Ethernet itself is not the bottleneck of data transmission
within local automation networks (for star topology
as well as for line topology—line topology means: each
control device assesses its own switch, and all traffic
has to pass through many or all switches). The present
bottleneck is the communication stack within the
end devices (Jasperneite Neumann, 2001a, 2001b,
Jasperneite, 2002).
2.2.2.2. Local soft RT approaches. As mentioned above
there are industrial approaches used in RT automation
applications. They are using shared and/or switched
Ethernet and TCP (UDP)/IP mechanisms. They can be
distinguished by different functionalities on top of TCP
(UDP)/IP as well as by their object models and application
process mechanisms. The systems based on Ethernet-TCP/
IP offer response time in the lower millisecond range. The
systems are capable but not deterministic. The data
transmission is based on the best effort principle. To use
these systems within the automation domain, mechanisms
are needed to monitor time limits, to use substitution
values, to optimise the transmission (using records of many
values within one MAC-PDU) as well as time and event-
triggered data transmission. A few examples are:
MODBUS TCP/IP (Schneider): MODBUS is an appli-
cation layer messaging protocol for Client/Server commu-
nication between devices connected via different types of
buses or networks. Using Ethernet as the transmission
technology, the Application Layer Protocol Data Unit (A-
PDU) of MODBUS (Function Code and Data) has been
encapsulated into an Ethernet frame. The Connection
Management on top of TCP/IP controls the access to TCP.
Ethernet/IP (Rockwell, ControlNet International, Open
DeviceNet Vendor Association) uses a Common Industrial
Protocol CIP (Ethernet/IP, 2003): IP stands for Industrial
Protocol (not for Internet Protocol). CIP represents a
common application layer for all physical networks of
Ethernet/IP, ControlNet and DeviceNet. Data packets are
transmitted via CIP router between the networks. For the
RT I/O data transfer, CIP works on top of UDP/IP. For the
Explicit Messaging, CIP works on top of TCP/IP. The
application process is based on a producer/consumer model.
High-speed Ethernet (HSE) (Fieldbus Foundation)
(HSE, 2001): A Field Device Agent represents a specific
Foundation Fieldbus application layer function (including
Fieldbus Message Specification). Additionally, there are
HSE communication profiles to support the different
device categories: host device, linking device, I/O gateway,
field device. These devices share the tasks of the system
using distributed Function Block applications.
Interface for distributed automation (IDA) (MODBUS-
IDA Group; Schneider) (IDA, 2002): The layer functions
allow three types of communication channels: Client/
Server Messaging for Engineering, data exchange for RT
traffic using RT middleware (RTPS Wire Protocol) from
RTI (Real-Time Innovations Inc, 2002) over UDP/IPv4.
The IDA concept has been used for the approach
‘‘MODBUS RTPS’’ (IEC, 2004b). The RTPS protocol
runs in a network of applications. There are two
communication models for the data transfer: a Publish/
Subscribe model for process data and a Composite State
Transfer model for exchange of state information.
PROFINET (PNO PROFIBUS user organisation, Sie-
mens) uses for its object model CBA (Component Based
Architecture) the DCOM Wire Protocol with the Remote
Procedure Call mechanisms (DCE RPC) (OSF C 706) to
transmit the soft RT data. An open source code and
various exemplary implementations/portations for differ-
ent operating systems are available on the PNO Website.
P-Net on IP (Process Data) (IEC, 2004d): Based on the
P-Net Fieldbus standard Type 4 (IEC, 2003a) the Public
Available Specification PAS contains the mechanism to use
P-Net in an IP environment. Therefore, the P-Net PDUs
are wrapped into UDP/IP packages, which can be routed
through IP networks. Nodes on the IP network are
addressed with two P-Net route elements. P-Net Clients
(Master) can access Servers on an IP network without
knowing anything about IP addresses.
All the mentioned approaches are able to support the
office domain protocols, e.g. SMTP, SNMP, HTTP, some
of them BOOTP, DHCP, for Web access and/or for
Engineering data exchange.
The object models of the approaches differ. Ethernet/IP
defines in the Common Industrial Protocol (CIP) specifica-
tion the user layer including an Application Object
Library (many standard objects of industrial devices) and
Device Profiles (defining the device features). HSE (2001) is
based on the Function Block technology (IEC 61499) to
design the distributed application as a Function Block
network. IDA and PROFINET (CBA) define a user-
friendly object background. IDA (MODBUS RTPS) (IDA,
2002) defines an object-oriented common Runtime and
Engineering model consisting of an Application Model
(design of modular applications), an Engineering Model
(description of the specific automation applications and
their connections), a Process Model (mapping the applica-
tion model elements to the physical topology), a Presenta-
tion Model (description of the external behaviour of the
application model elements) as well as an HMI Model
(browser-based supervisory and control). The Engineering
Model allows two views: the Functional view (representa-
tion of the hierarchical structure of the IDA system
functionality), the Topological view (physical network
structure including all segments and connected devices,
routers, switches).
ARTICLE IN PRESS

PROFINET CBA (PROFIBUS Guideline, 2003) also
defines an object-oriented common Runtime and Engineer-
ing Model (Fig. 1).
It allows the pre-configuration of the automation
application within the Engineering Tool and mapping it
to the physical architecture easily using a powerful tool.
2.2.2.3. Ethernet-based local hard RT approaches. As
mentioned above the use of middleware concepts on top
of TCP/IP leads to limits regarding RT behaviour caused
by the best effort features of TCP. That is why many
investigations are directed to use a middleware concept on
top of the MAC Layer. In academic and industrial
research, different scheduling strategies and smoothing
concepts are investigated (Alves et al., 2000; Bonaccorsi et
al., 2003; Caponetto et al., 2003; Carpenzano et al., 2002;
Haertig Loeser, 2004; Hoang et al., 2002; Kweon Shin,
2000; Thanikesavan Killat, 2004). Following the results
we can distinguish:
Deterministic (but not isochronous) RT behaviour
enabling cycle times in the range of 1–10 ms (RT class
2). That fulfils the timing requirements of most
industrial communications in a factory and can be
implemented by software.
Isochronous RT behaviour (RT class 3) enabling cycle
times in the range of 250 ms–1 ms and with jitters of less
than 1 ms. That fulfils the timing requirements of motion
control, especially for the synchronised operation of
many distributed drives.
Deterministic RT approaches (RT class 2): The first
concept uses a middleware on top of the MAC layer to
realise the scheduling and smoothing functions. The
middleware is normally represented by a software im-
plementation. Industrial examples are:
PROFINET (PROFIBUS International, Siemens) (IEC,
2004a).
Time-critical Control Network (Tcnet, Toshiba) (IEC,
2004h).
Vnet (Yokogawa) (IEC, 2004i).
For the Ethernet-based PROFINET IO system (using the
main application model background of the leading
Fieldbus PROFIBUS DP) the object model IO (input/
output) has been established. Fig. 2 depicts roughly the
protocol suite of a PROFINET system, containing the
connection establishment for PROFINET/CBA via con-
nection-oriented RPC on the left side as well as for the
PROFINET IO via connectionless RPC on the right side.
ARTICLE IN PRESS
Physical Device
(=Hardware)
Logical Device
(=Software)
LDev
(Logical Device) 1
1
*
PDev
(Physical Device)
1
*
ACCO
1
ACCO
(Active Control
Connection Object)
RTAuto
(Runtime
Automation)
Fig. 1. PROFINET CBA Object Model (PROFIBUS, 2002).
IO Context
Management
IEEE 802.3
Real-Time
IP
UDP
CL-RPC
TCP
DCOM
IP
CO-RPC
Component Object Model IO Object Model
Cyclic
(Producer/Consumer)
and acyclic Services
Connection
establishment
Connection
establishment
Component Context
Management (ACCO)
Fig. 2. PROFINET protocol suite (Neumann Po¨ schmann, 2005): (ACCO) Active Control Connection Object; (CO) connection-oriented; (CL)
connectionless; (RPC) Remote Procedure Call.

The exchange of (mostly cyclic) productive data uses the
RT functions in the centre.
The PROFINET IO service definition and protocol
specification (IEC, 2004a) covers the communication
between programmable logical controller PLC systems,
supervisor systems, and field devices or remote input and
output devices. The PROFINET IO specification complies
with IEC 61158, Part 5, Part 6 (IEC, 2003a, 2003b),
especially the Fieldbus Application Layer (FAL).
In general, PROFINET IO distinguishes between three
device types:
An IO controller, which represents mainly a PLC or
scanner.
An IO device, which represents mainly field devices or
remote IO devices.
An IO supervisor, which represents a diagnosis, HMI or
commissioning tool.
Real devices may be composed of several instances of the
above mentioned basic device types.
PROFINET IO defines its own layers and uses several
other standards. On top, the PROFINET IO application
process PROFINET IO AP has been defined. The
PROFINET IO application layer providing the PROFI-
NET IO specific services and protocol follows it. PROFI-
NET IO uses IETF and OSF standards for the OSI Middle
Layers, which has been empty in most known Fieldbus
architectures. PROFINET IO uses the Internet Standards
IP (RFC 791) and UDP (RFC 768) (IETF, 1980, 1981)
defined by the Internet Engineering Task Force (IETF).
Furthermore, the connectionless distributed communica-
tion environment remote procedure call CL DCE RPC
(OSF C 706), available from the Open Software Founda-
tion (OSF), defines the basis for context management and
generic read or write services. Between the application layer
and data link layer a glue layer for hard RT scheduling,
referred to as PROFINET IO link layer mapping protocol
machine PNIO LMPM, has been specified. It is responsible
for the precedence and timeliness of provider/consumer IO
data and alarm data, which bypass the OSI Middle Layers.
The lower layers comply to the IEEE (1998) standards
(IEC, 2001) with different physical media.
The PROFINET protocol is defined by a set of protocol
machines. For more details see (Neumann Po¨ schmann,
2005).
PROFINET provides a fair mechanism to restrict the
transmission performance of each device.
As shown in Fig. 3, the transmission of frames is divided
into different cycles at the local interface. Each cycle is
defined by TSendclock which can be configured between
31:25 ms and 4 ms. A typical value is 1 ms. The data to be
transmitted is ordered by priorities as follows: cyclic RT
data, acyclic RT data, non-RT data. At the beginning of a
cycle at tSendclock, the cyclic real-time (cRT) frames are
scheduled which are related to the IO Data ASE (ASE,
Application Service Entity). The number of frames depends
on the scheduled frames for the current phase and may also
be zero. The time for cRT frames should not exceed about
50% of the bandwidth for each cycle. Subsequently,
possible acyclic real-time frame (aRT) of the Alarm Data
ASE will be sent. The time for aRT frames should not
exceed about 10% of the bandwidth for each cycle.
Thereafter non-real-time frames (e.g. UDP/TCP) will be
sent during the rest of the available time (within T60%). A
safety margin of 40% is recommended. The TDMA
principle shown in Fig. 3 has been used by other systems
in an adequate way.
The Time-critical Control Network TCnet specifies in
the Application Layer a so-called ‘‘Common Memory’’ for
time-critical applications, and uses the same mechanisms as
mentioned for PROFINET IO for TCP(UDP)/IP-based
non-RT applications. An extended Data Link Layer
contains the Scheduling functionality. The Common
Memory is a virtual memory used and globally shared by
the participating nodes as well as the application processes
running in each node. It provides a temporal and spatial
coherence of data distribution. The Common Memory is
divided into numbers of blocks with several sizes of
memory. Each block is transmitted to the member
nodes using multicast services, supported by a node
publisher. A cyclic broadcast transmission mechanism
is responsible for refreshing the block data. Therefore,
the Common Memory consists of dedicated areas for each
node’s transmitting data to be refreshed. Thus, the
application program of a node has quick access to all
(distributed) data.
The Application Layer protocol (FAL) consists of three
protocol machines: FSPM FAL Service Protocol Machine,
ARPM (Application Relationship Protocol Machine) and
DMPM (Data Link Mapping Protocol Machine).
The Scheduling mechanism in the Data Link Layer
follows a Token Passing mechanism. The Target Rotation
Time depends on the desired cycle time. After a SYN
frame, broadcasted to all TCnet nodes, each node can send
its data within a preset time (holding the transmission
right). The data to be transmitted is ordered by priorities
ARTICLE IN PRESS
aRTcRT non RT aRTcRT non RT
tSendclock tSendclock+1
31,25µs=TSendclock=4ms
T60%
Fig. 3. LMPM MAC access used in PROFINET IO (Neumann
Po¨ schmann, 2005): (cRT) cyclic Real-Time; (aRT) acyclic Real-Time;
(non-RT) non-Real-Time; (MAC) Medium Access Control; (LMPM)
Link Layer Mapping Protocol Machine.

(high-speed cyclic data, medium-speed cyclic data, sporadic
message data, low-speed cyclic data). At the end of the
holding time the node transfers the transmission directly to
the next node. This means, this mechanism works
comparable to the time-slot principle used by PROFINET
IO (Fig. 3).
The Vnet supports up to 254 sub-networks with up to
254 nodes each. It realises in its Application Layer three
kinds of application data transfer:
One-way communication path used by an endpoint for
inputs or outputs (Conveyance Paths): unidirectional
Application Relationship (AR). To realise bi-directional
ARs (for transactions between communication end-
points), two of these Conveyance Paths have to be
established.
Trigger policy: There are two types: user-triggered type
requests the earliest opportunity for transmission of the
A-PDU by the Data Link Layer; network-scheduled type
supports the A-PDU transmission according to a
schedule configured by the management.
Data transfer using a buffer model or a queue model
(Conveyance Policy): For the buffer type, the AR
endpoints have a single buffer. Old data will be replaced
by new data. For the queue model type, queues at the
connection endpoints are used, ordered by a FIFO
principle without overwriting the transmitted data.
The Application Layer FAL contains three types of
protocol machines: FSPM FAL Service Protocol Machine,
ARPMs and DMPM.
For RT data transfer, the Data Link Layer offers three
Services: connection-less DL service, DL-SAP manage-
ment service, DL management service. The Scheduling of
the RT and non-RT traffic is located on top of the MAC
Layer. Therefore one or more time-slots can be used within
a macro-cycle (depending on the service sub-type). The
smallest macro-cycle is 10 ms. It is the time period in which
the transmission is controlled. The data can be ordered by
four priorities: urgent, high, normal, time-available. Each
node has its own synchronised macro-cycle. The Data Link
Layer maintains the clock synchronisation (less than 1 ms
within a sub-network, less than 5 ms across an extended
network).
Isochronous RT approach: Regarding RT class 3, the
following main examples are to become part of the
Fieldbus standard IEC 61158, Edition 4, in 2006:
Powerlink (Ethernet PowerLink Standardisation Group
EPSG, Bernecker Rainer), developed for Motion
Control (IEC, 2004f; Meindl, 2002).
EtherCAT (EtherCAT Technology Group (ETG),
Beckhoff) developed as a fast back plane communica-
tion system (IEC, 2004g).
PROFINET IO/Isochronous Technology (PROFIBUS
user organisation, Siemens) developed for any industrial
application (IEC, 2004a).
Ethernet/IP with Time Synchronisation (ODVA, Rock-
well Automation), an extension of Ethernet/IP (IEC,
2004c).
SERCOS III, developed for Motion Control (IG
SERCOS Interface e.V.) (IEC, 2004e).
Powerlink offers two modes: Protected Mode, Open Mode.
The Protected Mode uses a proprietary (BR) RT protocol
on top of the shared Ethernet for protected sub-networks.
These sub-networks can be connected to an open standard
network via router. Within the protected sub-network the
nodes exchange cyclically RT data avoiding collisions. The
scheduling mechanism is a time-division scheme. Every
node uses its own time slot (Slot Communication Network
Management SCNM) to send its data. The mechanism uses
a Manager Node, which acts comparable with a Bus
Master. The Managed Nodes are acting comparable with a
Slave. This mechanism avoids the collisions on the
Ethernet. The Powerlink protocol transfers the RT data
isochronously. The data exchanges occurring in a cyclic
framework based on a micro-cycle (Powerlink cycle) of
fixed duration, comparable with the mechanism depicted in
Fig. 3. Each cycle consists of four distinct phases (Start,
Cyclic, Asynchronous and Idle Periods). The cycle starts
with the message ‘‘Start of Cycle’’ (sent by the ‘‘Master’’ to
all ‘‘Slaves’’). Within the following ‘‘Cyclic Period’’ the
Controllers (Slaves) transmit after reception of a Poll
Request (unicast message) their isochronous traffic as Poll
Response (broadcast message), fully controlled by the
‘‘Master’’. This means, Powerlink is using the Publisher/
Subscriber communication model. After completing all
isochronous transactions of one cycle, the ‘‘Master’’
transmits an End of Cycle message, signalling the end of
the Cyclic Period. For asynchronous data traffic, the
‘‘Master’’ maintains a set of queues for different request
sources. It schedules the asynchronous transactions within
the Asynch Period. Using 100 Mbps Ethernet, Powerlink
allows real cycle times of 400 ms or less in applications. The
network jitter has been proven to be below 1 ms. The drives
(less than 50 with cycle times in the range of 2 ms) can
communicate synchronously with each other using broad-
cast services. Remarkable is that only hubs can be used for
such RT requirements in protected sub-networks. Switches
do not meet these demands.
The Open Mode can be used for TCP(UDP)/IP-based
applications. The network normally uses switches. The
traffic has to be transmitted within an asynchronous period
of the cycle.
EtherCAT distinguishes two modes: direct mode and
open mode. Using the direct mode, a Master Device uses a
standard Ethernet port between the Ethernet Master and
an EtherCAT segment. EtherCAT uses a ring topology
within the segment. The medium access control adopts the
Master/Slave principle, where the Master node (typically
the control system) sends the Ethernet frame to the Slave
nodes (Ethernet device). One single Ethernet device is the
head node of an EtherCAT segment consisting of a large
ARTICLE IN PRESS

number of EtherCAT Slaves. The Ethernet MAC address
of the first node of a segment is used for addressing the
EtherCAT segment. For the segment, a special hardware
can be used. The Ethernet frame passes each node. Each
node identifies its sub-frame and receives/sends the suitable
information using that sub-frame. Within the EtherCAT
segment, the EtherCAT Slave devices extract data from
and insert data into these frames. The EtherCAT Slave
devices process the incoming frames directly and extract
the relevant user data, or insert data and transfer the frame
to the next EtherCAT Slave device. The last EtherCAT
Slave device within the segment sends the fully processed
frame back. This frame is returned to the Master device as
a response frame. EtherCAT uses in the direct mode a
direct communication between a Master device and an
EtherCAT segment without switches. Thus, there is no
need for the direct addressing of nodes. For less time-
critical data traffic the data section of an UDP datagram
can be used (via IP routing). On the Master side any
standard UDP/IP implementation can be used.
Using the open mode, one or several EtherCAT segments
can be connected via switches with one or more Master
devices and Ethernet-based ‘‘Basic Slave’’ devices. Each
segment can be addressed using a ‘‘Segment Address
Slave’’ device (the head station of the segment).
The technical background of EtherCAT is 100Base-TX
and -FX Ethernet used within an EtherCAT segment and
between Master devices and Slave devices. Within Ether-
CAT segments, low-voltage differential signals (LVDS)
(IEEE 803-3ae-2002) can also be used.
The Application Layer follows the CANopen model.
There is an Object Dictionary and the handling of service
data and process data objects. The protocol is realised by
an EtherCAT state machine.
To enable isochronous data transfer, the Precision Clock
Synchronisation Protocol (IEC, 2002) is used.
PROFINET IO/Isochronous Technology uses a middle-
ware on top of Ethernet MAC layer to enable high-
performance transfer, cyclic data exchange and event-
controlled signal transmission. The layer 7 functionality is
directly linked to that middleware. The middleware itself
contains the scheduling and smoothing functions. This
means, TCP/IP does not influence the PDU structure. A
special Ethertype is used to identify RT PDUs (only one
PDU type for RT communication). This enables an easy
hardware support for the RT PDUs. The technical
background is a 100 Mbps full duplex Ethernet (switched
Ethernet). PROFINET IO adds an isochronous RT
channel to the RT channels of real-time class 2 option
channels. This channel enables a high-performance transfer
of cyclic data in an isochronous mode (Jasperneite,
Shehab, Weber, 2004). The time synchronisation and
node scheduling mechanism is located within and on top of
the Ethernet MAC Layer. The offered bandwidth is
separated in bandwidth for cyclic hard RT and soft/non-
RT traffic. This means, within a cycle there are separate
time domains for cyclic hard RT, for soft/non-RT over
TCP/IP traffic, and for the synchronisation mechanism, see
also Fig. 3. The cycle time should be in the range of 250 ms
(35 nodes) up to 1 ms (150 nodes) when simultaneously
TCP/IP traffic of about 6 Mbps is transmitted. The jitter
will be less than 1 ms. PROFINET IO/IRT uses switched
Ethernet (full duplex). Special 4 Port (followed by 2 Port)
switch ASICS has been developed and will allow the
integration of the switches into the devices (nodes)
substituting the legacy communication controllers of the
Fieldbus systems. Distances of 100 m per segment (elec-
trical) and 3 km per segment (fibre-optical) will be bridged.
Ethernet/IP with Time Synchronisation uses, based on
Ethernet/IP technology, the CIP Synch protocol to enable
the isochronous data transfer. Since the CIP Synch
protocol is fully compatible to standard Ethernet, addi-
tional devices without CIP Synch features can be used in
the same Ethernet system. The CIP Synch protocol uses the
Precision Clock Synchronisation Protocol (IEC, 2002) to
synchronise the node clocks using an additional hardware
function. CIP Synch can deliver time-synchronisation
accuracy of less than 500 ns between devices, which meets
the requirements of the most demanding real-time applica-
tions. The jitter between Master and Slave clocks can be
less than 200 ns.
SERCOS III: A SERCOS network consists of Masters
and Slaves. Slaves contain integrated repeaters, which have
a constant delay time Trep ðinput ! outputÞ. The nodes are
connected via point-to-point transmission lines. Each node
(participant) has two communication ports. The ports are
interchangeable. The topology can be either a ring
structure or a line structure. The ring structure consists of
a primary and a secondary channel. All slaves work in
forwarding mode. Through this ring, redundancy against
cable break is achieved. It is also possible to open the ring
and insert/remove slaves during operation (hot plug). The
line structure consists of either a primary or secondary
channel. The last physical slave performs the loopback
function. All other slaves work in forwarding mode. No
redundancy against cable break is achieved. It is also
possible to insert and remove slaves during operation (hot
plug). This is restricted to the last physical slave.
A control unit may have one or more master interfaces
depending on configuration. Each master handles only one
network on the physical layer. At the physical layer, a slave
represents the connection of one or more devices to the
network. Logically, one slave with several devices acts the
same as several slaves with one device each. Communica-
tion between the master and the slaves as well as the cross
communication between the slaves (must be configured
during the commissioning phase, especially configuring the
device telegrams) are supported. The physical arrangement
of slaves in the network is independent of the predefined
device. Any slave can recognise the topology at any time,
since there is a distinction between primary and secondary
telegrams. This is important when a slave has been added
to the communication during operational phase (hot plug).
When a slave receives telegrams with the same SERCOS
ARTICLE IN PRESS

type on both ports it recognises a line. When it receives a
primary telegram on one port and a secondary telegram on
the other port, it recognises a ring. The Physical Layer is
based on Ethernet hardware. The used MAC principle is
CSMA/CD.
SERCOS III allows the transmitting of telegrams related
to Ethernet services and two types of SERCOS telegrams
(Master Data Telegram, MDT, Device Telegram AT).
MDTs transmit data from master to slaves, ATs transmit
data from the slaves to the master. SERCOS telegrams
are not addressed individually to each slave. Instead they
are common to all slaves. Slots within these telegrams are
individually allotted to each slave. The slave can then read
in its slot the data that is addressed specifically to it by the
master, and can write data, which is addressed to the
master. The Data Link Layer provides synchronous cyclic
services following the time slot principle unaffected by the
message traffic. Within the cycle time TScyc a number of
service channels SVC and of RT data fields RTD (both
representing a ‘‘RT Channel’’) as well as an ‘‘IP Channel’’
(optionally used) can be allocated. Additionally, there is a
hot plug field for logging off or on of participating slaves
and a synchronisation field. SVC supports the transmission
of non-RT data within the RT channel. A master is able to
support a separate service channel for each connected
device. The cycle time can be set to 31.25, 62.5, 125, 250 ms
and integer multiples of 250 ms. The jitter is limited to 1 ms
(high-performance class) or 50 ms (low-performance class).
At the Application Layer two kinds of services are
supported: AL services mapped onto TCP(UDP)/IP
protocol suite; RT services realised using five ‘‘Commu-
nication Phases’’ CP: from recognising the participating
slaves by the master up to the validation of the transmitted
data. The synchronisation is generated once per commu-
nication cycle. For the synchronisation, the communica-
tion phases 0–3 are necessary:
CP0: measurement of the ring delays, determination of
synchronisation time.
CP2: transmission of the synchronisation time to all
slaves.
CP3: with ‘‘CP3 transition check’’ the synchronisation
within the slave is activated.
2.2.3. Further development
The further development of local industrial communica-
tions addresses five topics:
Improvement of the technology.
System architectures.
Organisation.
Engineering.
Standardisation.
The improvement of the technology refers to the further
development of Ethernet (not discussed here) and the
required support of RT communications by the operating
systems and switch technology. The operating systems have
to enable multiple queues for non-RT as well as for RT
traffic. These queues have to provide Priority policies and
not only First-Come-First-Serve policies, separately for the
queues. The switches have to support the preferential
access of data packages to high priority ports to enable the
preferential access of data packages to the transmission
line. The audio and video stream transmission is of less
interest in the automation domain. Another important
topic is the investigation and the improvement of schedul-
ing methods to control the data traffic on top of the MAC
layer.
Regarding the system architecture there are the following
areas of interest:
Topology: The upcoming line topology used in the
industrial communications domain enables an easier
installation of cables, but reduces the performance of the
switched Ethernet (Jasperneite, 2002). There is enough
reserve within the Ethernet technology to compensate this.
The advantage is that the network components can be
allocated directly to the automation devices instead of a
legacy communication controller. The tree topology
improves the performance of the network, but requires a
larger effort for installation of cables. The network
components have to be allocated. Methods for the design
of an optimal topology are necessary.
Web Server allocation: There is an increasing interest of
end users to outsource important activities (e.g. main-
tenance) or to support the internal performance manage-
ment, diagnoses, etc. For these purposes different kinds of
‘‘Application Servers’’ (e.g. diagnosis server, asset manage-
ment server, maintenance server) will be installed using
Web services. The allocation depends on the available
performance, security policy and competencies.
Fieldbus integration: More than 25 million installed
Fieldbus nodes are running worldwide. There is an interest
to integrate the legacy Fieldbus systems into the commu-
nication hierarchy. One of the most often used principles is
the proxy concept to map the data within the Fieldbus
system via a Proxy Device onto the Ethernet-based
industrial communication system. Another important task
is to map the device descriptions of the Fieldbus devices
into the configuration tools of the Ethernet-based indus-
trial communication system.
Organisation: Office and industrial communication
systems are merging in the middle levels of an enterprise
hierarchy. Since they are using an increasingly common
Ethernet-based communication infrastructure, there are
conflicts in terms of competencies. The IT department
administrates the network and has the sovereignty of the
ports, but the control engineers do not accept any access to
the resources used by the automation system. There are
necessary technical approaches (lock mechanisms) to solve
this conflict.
The methods of the Engineering of complex Ethernet-
based RT networks seem to be a long-term topic for
academic and industrial investigation. The prediction of a
ARTICLE IN PRESS

required performance as well as the computer-aided
configuration and parameterisation are of main interest.
It requires methods to design the semantics of the
networked control system (information models) as well as
suitable syntaxes following description standards (e.g.
Electronic Device Description (EDD) or Field Device
Tool technology), both in the standardisation process
by IEC.
Standardisation: The maintenance phase of the Fieldbus
standard IEC 61158 started in November 2005. As a result
the Edition 4 of that standard will be available at the end of
2006. The different types of Ethernet-based industrial
communication systems (IEC, 2004a–i) will become part of
that standard. Some of these systems can run on the same
cable, but are not interoperable. Thus, the normal case will
be that each system will work alone in a certain application
by commercial reasons.
2.3. Wide area communications
Allowing remote mechanisms (remote supervisory,
operation, service) using Wide Area Networks, the stock
of existing communication technology becomes broader:
All appearances of the Internet (mostly with best effort
quality of services).
Public digital wired telecommunication systems (ISDN,
DSL etc.).
Public digital wireless telecommunication systems
(GSM-based, GPRS-based, UMTS-based).
Private wireless telecommunication systems, e.g. trunk
radio systems.
Using these technologies within the automation domain
there are many private protocols over leased lines,
tunnelling mechanisms, etc. Most of the wireless radio
networks can be used in non-RT applications, some of
them in soft RT applications (but industrial environments
and ISM Band limit the applications). The behaviour of the
end-to-end connection via these telecommunication sys-
tems depends on the recently offered quality of service
(QoS) and cannot be guaranteed in many cases. It strongly
limits the use of these systems within the automation
domains.
2.4. RT behaviour of heterogeneous networks
There are different levels of RT behaviour within a
heterogeneous network used in the automation domain
depending on the level of the enterprise network. In
contrast to a high priority of stream transmission, in the
industrial automation application the data packet transmis-
sion has to have the highest priority. Within the automa-
tion domain, there are other requirements of RT behaviour
of the Wide Area Networks (WAN) than for other
domains (office, e-commerce, etc.). The most important
requirement is to guarantee response time of data packages
(application-specific deadlines), whatever the required
value of the deadline in the various applications is. Using
WAN, the actual offered mechanisms mainly support the
best effort QoS and privilege the video and audio stream
transmission. There is a need for offering QoS levels that
are required for suitable response behaviour of data packet
transmission. The IPv6 approach offers RT mechanisms,
user priorities and a broader range of addresses. This is
very important for the over-boarding need of address space
using embedded Web servers within the automation
devices. In the last few years, a stable IPv6 network
supported by different providers has been established.
The usage of WAN within the automation domain has
to be investigated just as the uninterrupted commercial
availability. Since the Internet or other telecommunication
systems are general-purpose communication systems, the
infrastructure and business model preconditions for the
selection of requested QoS within a spectrum of available
communication services of various providers have to be
developed (Fig. 4). This means, in analogy to the
‘‘switched’’ Ethernet in LANs, a WAN switching mechan-
ism has to be developed for this selection, i.e. choosing
dynamically the network type and/or network provider
who guarantees the required QoS. There are many
investigations to use the IPv6 functionality for RT services,
mostly directed to the usage for audio/video stream
transmission (Tseng, Lee, Liu, 2001; Mahmoodian
Haring, 2000; Moon Aghvami, 2001; Chen Huang,
2000).
3. Wireless industrial communications within the automation
domain
3.1. Wireless Fieldbus systems
A wireless Fieldbus system is a wireless communication
network suitable for use at the device level of an
automation system. For that purpose, Wireless Local Area
Networks (WLAN) and Wireless Personal Area Networks
(WPAN) can be employed. Inline with the development of
radio technologies, different vendors of Fieldbus systems
(e.g. CAN, Interbus, PROFIBUS) investigated the replace-
ment of wired transmission lines by radio front-ends (see
e.g. Rauchhaupt, 1999; Rauchhaupt Ha¨ hniche, 1999;
FUNBUS, 2000; Pohlmann, 2005), followed by the
European project ‘‘RadioFieldbus’’ (RFieldbus) (Rauch-
haupt, 2002, 2003; Ferreira, Alves, Tovar, 2002).
The RFieldbus technology requires additional protocol
mechanisms and contains the scheduling of RT and non-
RT traffic (Fig. 5).
The RFieldbus Radio Physical Layer main properties
are:
ISM-Band 2.4 GHz, Synchronous Octet Transmission.
Direct Sequence Spread Spectrum (DSSS) Coding, code
lengths 11–63 chips.
Radio Data Rate 350 kbit/s–1 Mbit/s–2 Mbit/s.
ARTICLE IN PRESS

Two Physical Layer Mode Options can be used:
Mode I compatible with IEEE 802.11 MAC-less
(IEEE802.11 header; extensions for identiﬁcation,
mobility, power management).
Mode II optimised for RT transmission (shortened
preamble; optimised synchronisation).
Signal quality and power management for RT hand-
over; transmission quality supervision.
The RFieldbus architecture has been proved for the world-
wide leading Fieldbus PROFIBUS. It contains additional
functionality for web-based services enabling an access of
ARTICLE IN PRESS
CEPremote
Remote industrial domain
CEPlocal
Local industrial domain
Public and Private
Telecommunication
Networks
(wired/wireless)
Public Network 1
. . .
. . .
Public Network m
Private Network 1
Private Network n
QoS 1
QoS k
Agreements with
providers are
necessary to
guarantee the
required QoS
Fig. 4. Needed Provider Switch Mechanism: (CEP) Connection End Point; (QoS) Quality of Service.
MultiMedia
Application
(ClientorServer)
PROFIBUS-DP
Application
(Master or Slave) TCP/IPStack
IP Mapper
Data Communication
Equipment Independent
Sublayer (DIS)
System Management
Application
Station Management
PRO FIBUS-DPV1 AL
Data Communication
Equipment (DCE)
IP ACS
DP Mapper
DP/IP Dispatcher
PROFIBUS DL DLX
Data Communication
Equipment (DCE)
wired (RS 485) wireless (ISM Band)
Data Communication
Equipment Independent
Sublayer(DIS)
Fig. 5. Protocol Suite of a Radio-based Field Device (PROFIBUS) (Rauchhaupt, 2003): (ACS) Admission Control and Scheduling; (DL) Data Link
Layer; (DLX) Data Link Layer Extension; (DP) Decentral Periphery; (DPV1 AL) enhanced DP Application Layer; (IP) Internet Protocol.

‘‘multimedia’’ applications to the physical transmission
channel via TCP/IP functionality. Fig. 5 depicts the
necessary mixed protocol stack for both the (mostly cyclic)
RT traffic (process data, control data) on the left side and
the non-RT (acyclic) traffic (remote services).
Within the RFieldbus project a special radio technology
has been used, since the standard radio technologies did
not support required features. These features are now
available. Thus, the further development can use these
features (e.g. Rake receivers to avoid the influence of
obstacles). Other investigations were directed to extend the
PROFIBUS by WLAN (Willig, 2003), and by Bluetooth
front-ends (Miorandi Pitturi, 2004).
An interesting proprietary Wireless Sensor/Actuator
Network (‘‘Wireless Interface for Sensors and Actuators’’
WISA) has been developed by ABB (Scheible, Endresen,
Frey, 2005). General features are:
Frequency Division Duplex (FDD): Uplink and Down-
link on different frequencies.
Frequency Hopping (FH): Uplink and Downlink hop
after each frame, frame length: 2.048 ms.
Several Uplinks and Downlink (FDMA) are using
different frequencies.
Time Division Multiple Access (TDMA): Sensor/Ac-
tuator sends within its own time slot.
Collision Avoidance (CA).
Frequency range: 2.45 GHz.
Power consumption: o1 mW.
WISA uses dedicated slot-based links between Base
Stations BS and Sensor/Actuator Stations SA:
Connection between Base Station BS and Sensor/
Actuator Station SA: Downlink (16 downlinks).
Connection between SA and BS: various Uplink groups
via different antennas (30 SAs pro uplink group, uplink
frames divided in 32 slots).
3.2. Wireless industrial communications within the
enterprise
Interesting approaches/standards in the context of
Industrial Wireless communications may be grouped as
follows:
Proprietary protocols for radio technologies (not further
discussed here; see 3.1).
Lower layer standards (IEEE 802.11 and 802.15) based
on WLAN, Pico Networks and Sensor/Actuator Net-
works.
Higher layer standards (specific Application Layer on
top of IEEE 802.11 and 802.15.1 and 4, e.g. Wireless
Fidelity, Bluetooth, ZigBee).
Complete standards of mobile communications (GSM,
GPRS, UMTS) and wireless telephones (DECT), not
discussed here.
Ultra Wideband technology UWB, e.g. based on IEEE
802.15.3a.
Most of these wireless radio networks can be used in non-
RT applications, some of them in soft RT applications, but
industrial environments and ISM band limit their applica-
tions (Akyildiz, Su, Sankarasubramaniam, Cayirci, 2002;
Akyildiz Kasimoglu, 2004; Decotignie, 2002; Willig,
2003). Nolte, Hansson, and Lo Bello (2005) gives an
overview of wireless automotive communications and
compares the technologies.
The WLAN technology is being more and more
introduced in the higher architecture levels of the automa-
tion hierarchy, as well as the shop floor.
Bluetooth (Bluetooth SIG), originally developed for
small range communication in the consumer market
(home, PC/Notebooks, mobile phones, PDAs), is becom-
ing increasingly interesting for the automation domain.
Bluetooth (Piconet) consists of:
Standard IEEE 802.15.1 (lower layers).
Higher layer Specifications of Bluetooth SIG.
Profiles of Bluetooth SIG.
Bluetooth uses asynchronous data connections with asym-
metric transmission between 1 Master and 256 Slaves (up
to 7 Slaves can be active Slaves). The range depends on the
sender performance (max. 10 m for normal applications,
max. 100 m for special applications). Currently, the
Scatternet is in discussion. Within Scatternet, devices can
be active in different Piconets. There are successful
Bluetooth applications in automation (e.g. Weczerek,
2005; Lu¨ hrs, 2005).
ZigBee (ZigBee Alliance) should be introduced to
connect the automation devices at the field level, especially
in the process automation with their specific RT require-
ments, because it will operate on a lower baud rate, but
fortunately with low-power consumption. ZigBee consists
of:
Standard IEEE 802.15.4 (lower layers).
Specifications by ZigBee Alliance (higher layers).
Profiles by ZigBee Alliance.
The main features of ZigBee are:
Low-power wireless communications.
Less complex protocol stack.
Very fast ‘‘Awake Phase’’ changing from power saving
sleep modus to the operation modus.
Meshed network topology is possible.
Redundant transmission paths are possible.
Targeted application areas of ZigBee are the consumer
market, building automation, and industrial automation
(the focus from the beginning). Thus, the specification will
be in principle suitable for sensor networks. But up to now,
ARTICLE IN PRESS

no profiles for applications in industrial automation are
specified. The specification has been available since the end
of 2004, but not all necessary functions were specified. First
implementations are available (but with limited functions).
Ultra Wideband Systems (UWB) are becoming more
and more important for sensors and indoor location-based
services. But at the moment their use is limited, because
they are using the same frequency band as GSM based cell
phones. The standardisation activities lead to the standard
IEEE 802.15.3a. Interested Alliances are WiMedia Alliance
and Multiband OFDM Alliance (MBOA SIG). These
alliances are targeting both the specification of UWB
approaches and related certification programs. Targeted
product areas are consumer electronics, mobile devices,
and PCs.
4. Functional safety
Safety means protection against hazards (movement,
heat, radiation, electrical shock, etc.) (IEC, 2000). ‘‘Func-
tional Safety’’ means protection against hazards caused by
incorrect functioning. Safety includes the communication
via a heterogeneous network. CENELEC (2001, EN
50159), Halang and Konakovsky (1998), Halang and
Colnaric (2002), Diedrich, Wollschla¨ ger, and Hintze
(2003), Mataix et al. (2003) deal with different aspects of
safety in communications and computer systems. Caused
by the distribution of data via the communication net-
works, the safety of these networks is becoming more and
more important regarding the functionality of an automa-
tion system.
There is a need to meet defined Safety Integrity Levels
(SIL, see IEC 61508), e.g. Residual Error Probability
p10À7
errors=h for SIL 3 (Neumann, 2002). The commu-
nication part requires a residual error probability of
p10À9
errors=h for SIL 3 (1% of 10À7
; the remaining
99% are required for sensors, PLCs, and actuators, etc.).
Measures to avoid the influence of the failures (falsified
addresses, loss or damage of data, delay) could be:
Numbering of transmitted data.
Observation of transmission time (time expectation).
Authentication using passwords (identification).
Optimised CRC (redundancy).
One principle to use communication systems for safety
applications is to consider the communication channel as a
so-called ‘‘Black Channel’’ (IEC, 2003c). This means all
safety-related functions will be realised outside (on top of)
the communication layers. The safety measures will be
realised in a separated safety layer that is situated between
communication protocol and application. With this prin-
ciple, an existing communication system can be used as it
is—and with existing components like ASICs, cables,
connectors, repeaters, links, etc. as far as they meet the
electrical requirements. Such solutions exist for several
Fieldbus protocols (e.g. Interbus Safety online, 2005;
PROFIsafe online, 2005; SafetyBus p online, 2005). The
background has to be mapped to Ethernet-based and
heterogeneous networks (Virtual Automation Networks,
VAN). Investigations are necessary on how TCP/IP-
oriented networks can be extended for the transfer of
safety-related data in automation systems.
IEC 61508 (IEC, 2000) defines Safety Integrity Levels
(SIL) for electrical, electronic and programmable electronic
devices, which contain the permissible residual error
probabilities and error detection rates. It is necessary to
prove that the used safety codes fulfil these requirements—
especially for different types of communication media. The
results should be introduced in the proposed new IEC
standardisation activities on ‘‘Profiles for functional safe
and secure communications in industrial networks’’ (IEC,
2003c).
5. Security
Today’s automation islands are relatively secure against
attacks. In the case of Internet usage, the reasons of
growing attack probability are:
Many people have remote access to these systems.
Remote access enables attacks by using public tele-
communication systems and Internet.
The usage of Internet-based technologies compared with
today’s automation islands requires a common security
concept for distributed automation using Virtual Automa-
tion Networks. Dietrich, Treytl, and Sauter (2004), Fritz
and Halang (2002), Fuhrberg (2000), Ho¨ ne and Eloff
(2001), Naedele, Dzung, and Stanimirov (2001), Palensky
and Sauter (2000), Schneider (2002), Schultz (2002),
Schwaiger and Treytl (2003), Treytl, Sauter, and Schwaiger
(2004) deal with several aspects of security in communica-
tion systems.
Security criteria are:
Confidentiality of information (to protect against access
by unauthorised third parties).
Integrity of information (detection of unauthorised
modification or manipulation of message contents with
a specified level of confidence).
Timeliness or sequencing of message delivery (detection
of any unauthorised message re-timing, re-sequencing or
replay of prior messages).
Authentication and authorisation of communication
peers (verification of identity of a communication peer
and that peer entitlement).
Availability of information.
The question is how Ethernet and/or TCP/IP-oriented
networks have to be secured under specific automation
conditions such as low resources and easy to use
configuration in production environments.
ARTICLE IN PRESS

Special control network administration services could
not be accepted. This means, the handling of physical
automation device addresses is not allowed. Thus, within
the automation domain logically addressed device groups
have to be secured. Typical types of assaults are:
eavesdropping, hacker attacks, data corruption, un-
authorised access, espionage, sabotage, loss, theft, and
operator errors.
Many arguments are given why defence-in-depth with
multiple, staged, complementary security mechanisms is
the suitable approach. There are different abstraction levels
and security zones within a Virtual Automation Network.
Different types of mechanisms against attacks by remote
access are used concurrently around and inside each
security zone to defend this. The outer zones contain less
valuable targets. The safety-critical automation system is
placed in the innermost zone. Investigations should lead to
the designation of security zones (e.g. Remote Access Zone,
Local Plant Operator Zone, Automation Device Zone),
and to existent security mechanisms used in all or specific
zones (e.g. authorisation, intrusion detection, response,
mechanism protection, specific security mechanisms for
industrial communications). Naedele (2003) describes the
approaches in principle. Adamczyk, Bahrs, Thierse, and
Werner (2004), Naedele (2004), Wolframm (2004) deal with
different aspects of an approach.
In addition to defence mechanisms, also detection
mechanisms could be helpful which allow the automation
system operators to detect attacks, and reactive mechan-
isms and processes to actively defend against them. Each
zone also has to spend time to detect and fend off the
attacker.
6. Local awareness in industrial automation
The usage of Information Technologies within the life
cycle of an automation system is becoming broader. The
Engineering in the various phases (design, development,
manufacturing and commissioning of automation devices
and systems, maintenance of the system) is becoming more
efficient using formal methods to develop information
models and description languages (describing the features
of the components for all the mentioned phases) and
computer-aided tools to handle these features. UML can
be used as a tool background for the development of
information models. The Electronic Device Description
Language (EDDL), standardised in IEC 61804, can be
used to describe the device features based on the
information models. An alternative way is the Field Device
Tool (FDT) technology, currently under standardisation in
IEC. An important requirement is a context-sensitive offer
of the needed information at these tools. Since the needed
database is distributed through the decentralised automa-
tion system (connected by the heterogeneous network) it
also requires location-based services. The recent ap-
proaches use Web technologies to organise access to the
remote data. Since the remote access raises the probability
of attacks to the system, the security becomes more
important. Additionally, a unified data structure describing
the features of the installed devices has to be standardised.
At the moment, there are various profiles in the Fieldbus
domain. These profiles have to be mapped to the
heterogeneous networks.
7. Conclusions
Future scenarios of distributed automation require more
mechanisms for the geographical distribution of automa-
tion functions. The resulting automation system has to
offer location-based and context-sensitive services to
guarantee suitable local and remote functions for different
user needs (remote operation, remote service) and requires
RT data transmission, safety and security mechanisms.
It requires a special communication network—a Virtual
Automation Network (VAN). A VAN is a heterogeneous
network consisting of wired and wireless LAN, the
Internet, and wired or/and wireless telecommunication
systems. This means that geographically distributed
applications, co-operating to fulfil a control application,
are connected via this VAN accessed by remote connection
endpoints. World-wide distribution of Internet offers the
Automation domain a good infrastructure but introduces
many additional problems, which need to be solved.
References
Adamczyk, H., Bahrs, U., Thierse, P. J., Werner, T. (2004). IT security
regarding Engineering and plant maintenance over public networks.
VDE congress, Berlin, pp. 219–226 (in German).
Agarwal, A., Wang, K. B. (2003). Supporting quality of service in IP
multicast networks. Computer Communications, 26(14), 1533–1540.
Akyildiz, I. F., Kasimoglu, H. (2004). Wireless sensor and actor
networks: Research challenges. Ad Hoc Networks Journal, 2(2),
351–367.
Akyildiz, I. F., Su, W., Sankarasubramaniam, Y., Cayirci, E. (2002).
Wireless sensor networks: A survey. Computer Networks, 38(4),
393–422.
Alves, M., Tovar, E., Vasques, F. (2000). Ethernet goes real-time: A
survey on research and technological developments. Technical Report
HURRAY-TR-0001, Polytechnic Institute of Porto.
Bonaccorsi, A., Lo Bello, L., Mirabella, O., Neumann, P., Po¨ schmann,
A. (2003). A distributed approach to achieve predictable Ethernet
access control in industrial environments. Fifth IFAC international
conference on Fieldbus systems and their applications (FET 2003)
Aveiro: Proceedings (pp. 173–176).
Caponetto, R., Lo Bello, L., Mirabella, O. (2003). Experimental
assessments of fuzzy smoothers for Ethernet networks. 15th Euromicro
conference on real-time systems, Porto 2003: Proceedings (pp. 57–60).
Carpenzano, A., Caponetto, R., Lo Bello, L., Mirabella, O. (2002).
Fuzzy traffic smoothing: An approach for real-time communication
over Ethernet networks. Fourth IEEE international workshop on
factory communication systems WFCS’02, Va¨ stera˚ s (pp. 241–248).
CENELEC (2001). EN 50159. Railway applications: Requirements for
safety-related communication in closed transmission systems.
Chen, W.-T., Huang, L.-C. (2000). RSVP mobility support: A signalling
protocol for integrated services Internet with mobile hosts. IEEE
INFOCOM 2000 (pp. 1283–1292).
Choi, B.-Y., Song, S., Birch, N., Huang, J. (2000). Probabilistic
approach to switched Ethernet for real-time control applications.
ARTICLE IN PRESS

Seventh international conference on real-time computing systems and
applications 2000: Proceedings (pp. 384–388).
Decotignie, J.-D. (2002). Wireless Fieldbusses—a survey of issues and
solutions. 15th triennial world congress of the international federation of
automatic control, Barcelona.
Diedrich, C., Wollschla¨ ger, M., Hintze, E. (2003). UML specification
and development of safety-relevant industrial communication systems.
Fourth MATHMOD—fourth IMACS symposium on mathematical
modelling, February 5–7, 2003, Vienna University of Technology,
Austria.
Dietrich, D., Treytl, A., Sauter, T. (2004). IT security of Fieldbus
networks. Recent and future aspects. VDE congress, Berlin
(pp. 227–232) (in German).
Dolejs, O., Hanazalek, Z. (2003). Simulation of Ethernet for real-time
applications. IEEE international conference of industrial technology
(ICIT 2003) (pp. 1018–1021).
Ethernet/IP specification (2001), Release 1.0. June 5, 2001, ControlNet
International and open DeviceNet Vendor association.
Fan, X., Wang, Z., Sun, Y. (2002). How to guarantee factory
communication with switched Ethernet: Survey of its emerging
technology. IEEE 28th annual conference, industrial electronics society.
Ferreira, M., Alves, M., Tovar, E. (2002). Hybrid wired/wireless
PROFIBUS networks supported by bridges/routers. Fourth IEEE
international workshop on factory communication systems, Va¨ stera˚ s
(pp. 193–202).
Fritz, R., Halang, W. A. (2002). Secure virus defence. Datakontext;
ISBN 3-89577-266-6 (in German).
Fuhrberg, K. (2000). Internet security. Published as Online documentation of
Bundesamt fu¨ r Sicherheit in der Informationstechnik hwww.bsi.bund.de/
literat/doc/sinetdoc/sinetstd.htmi. 1997, Rev. 02.03.2000 (in German).
FUNBUS (2000). The BMBF Project ‘‘Wireless Fieldbus systems in the
factory’’. Funding no.: 02PV4060, Report, Okt. 2000, INTERBUS
CLUB, Order No. TNR5121324 (in German).
Furrer, F. J. (2003). Industrial automation with Ethernet—TCP/IP and web
technologies (3rd ed.). Hu¨ thig (in German).
Georges, J.-P., Rondeau, E., Divoux, T. (2002a). How to be sure that
switched Ethernet networks satisfy the real-time requirements of an
industrial application? IEEE international symposium on industrial
electronics, ISIE 2002 (Vol. 1, pp. 158–163).
Georges, J.-P., Rondeau, E., Divoux, T. (2002b). Evaluation of
switched Ethernet in an industrial context by using the network
calculus. IEEE fourth workshop on factory communication systems
WFCS’02, Va¨ stera˚ s (pp. 19–26).
Gorka, J. (2005). 1394automation. Results and further steps. Polyscope,
37(3), 27–29 (in German).
Haertig, H., Loeser, J. (2004). Using switched Ethernet for hard real-
time communication. International conference on parallel computing in
electrical engineering (PARELEC 2004), September 2004, Dresden,
Germany (pp. 349–353).
Halang, W., Konakovsky, R. (1998). Dependable software. Auto-
matisierungstechnik 46, special issue Sicherheitsgerichtete Automatisier-
ungstechnik 2, Oldenbourg, 93–103 (in German).
Halang, W. A., Colnaric, M. (2002). Dealing with exceptions in safety-
related embedded systems. 15th triennial world congress of the
international federation of automatic control, Barcelona.
Hoang, H., Jonsson, M., Hagstrom, U., Kallerdahl, A. (2002). Switched
real-time Ethernet and earliest deadline first scheduling-protocols and
traffic handling. 10th international workshop on parallel and distributed
real-time systems, Fort Lauderdale, Florida, USA, April 2002.
Ho¨ ne, K., Eloff, J. H. P. (2001). Information security policy—what do
international information security standards say? Computers
Security, 21(5), 402–409.
HSE (2001). High speed Ethernet specification documents FF-801, 803,
586, 588, 589, 593, 941. Fieldbus Foundation, Austin 2001.
IDA (2002). IDA Group. IDA—interface for distributed automation.
Architecture description and specification. Revision 1.1, November
2002.
IEC (2000). IEC 61508: functional safety of electrical/electronic/program-
mable el. Safety-related systems.
IEC (2001). ISO/IEC 8802-3. Information technology—telecommunica-
tions and information exchange between systems—local and metro-
politan area networks—specific requirements—Part 3: Carrier sense
multiple access with collision detection (CSMA/CD) access method
and Physical Layer specifications.
IEC (2002). IEC 61588: precision clock synchronization protocol for
networked measurement and control systems.
IEC (2003a). IEC 61158 series, edition 3: Digital data communication for
measurement and control—Fieldbus for use in industrial control
systems.
IEC (2003b). IEC 61784-1. Digital data communications for measurement
and control—Part 1: Profile sets for continuous and discrete
manufacturing relative to Fieldbus use in industrial control systems.
IEC (2003c). IEC 65C/307/NP. Digital data communications for
measurement and control—profiles for functional safe and secure
communications in industrial networks, New Work Item Proposal,
2003.
IEC (2004a). IEC 65C/359/NP. Real-time Ethernet: PROFINET IO.
Application Layer Service Definition Application Layer Protocol
Specification.
IEC (2004b). IEC 65C/341/NP. Real-time Ethernet: MODBUS-RTPS.
IEC (2004c). IEC 65C/361/NP. Real-time Ethernet: EtherNet/IP with time
synchronization.
IEC (2004d). IEC 65C/360/NP. Real-time Ethernet: P-NET on IP.
IEC (2004e). IEC 65C/358/NP. Real-time Ethernet: SERCOS III.
IEC (2004f). IEC 65C/356/NP. Real-time Ethernet: POWERLINK.
IEC (2004g). IEC 65C/355/NP. Real-time Ethernet: ETHERCAT.
IEC (2004h). IEC 65C/353/NP. Real-time Ethernet: TCnet (Time-critical
control network).
IEC (2004i). IEC 65C/352/NP. Real-time Ethernet: Vnet/IP.
IEEE (1998). IEEE 802.1Q: IEEE standards for local and metropolitan
networks: Virtual bridged local area networks, 1998.
IETF (1980). RFC 768. User datagram protocol. IETF, available at
hhttp://www.ietf.orgi.
IETF (1981). RFC 791. Internet protocol. IETF, available at hhttp://
www.ietf.orgi.
Interbus Safety online (2005). Available at: hhttp://www.interbusclub.
com/de/news/Fly_Basics_IB_Safety.pdfi.
Jasperneite, J. (2002). Leistungsbewertung eines lokalen Netzwerkes mit
Class-of-Service Unterstu¨tzung fu¨r die prozessnahe Echtzeitkommunika-
tion. Aachen: Shaker. ISBN 3832208321.
Jasperneite, J., Neumann, P. (2001a). Switched Ethernet for factory
communication. IEEE conference on emerging technologies and
factory automation (ETFA’01), Antibes Juan-les-pins, France
(pp. 205–212).
Jasperneite, J., Neumann, P. (2001b). Performance evaluation of
switched Ethernet in real-time applications. Fourth international
conference on Fieldbus systems and their applications, FET2001, Nancy
(pp. 144–151).
Jasperneite, J., Shehab, K., Weber, K. (2004). Enhancements to the time
synchronization standard IEEE—1588 for a system of cascaded
bridges. Fifth IEEE international workshop on factory communication
systems, WFCS2004, Vienna, Austria (pp. 239–244).
Kweon, S.-K., Shin, K. G. (2000). Achieving real-time communication
over Ethernet with adaptive traffic-smoothing. Sixth IEEE conference
on real-time technology and applications symposium, RTAS, Washington,
DC (pp. 90–100).
Kweon, S.-K., Shin, K. G., Zheng, Z. (1999). Statistical real-time
communication over Ethernet for manufacturing automation systems.
Fifth real-time technology and applications symposium (pp. 2–4).
Lee, K. C., Lee, S. (2002). Performance evaluation of switched Ethernet
for networked control systems. IEEE 28th international conference on
industrial electronics, control, and instrumentation (IECON 2002)
(pp. 3170–3175), Industrial Electronics Society.
Liu, W. S. (2000). Real-time systems. Englewood Cliffs, NJ: Prentice-Hall.
ARTICLE IN PRESS

Loeser, J., Haertig, H. (2004). Low-latency hard real-time communica-
tion over switched Ethernet. 16th EURIMICRO conference on real-
time systems ERTS 2004 (pp. 13–22).
Lu¨ hrs, C. (2005). HMI with Bluetooth—from application to integration.
Workshop on radio-based communications in industrial automation,
Du¨ sseldorf, Mai 2005 (in German).
Mahmoodian, A., Haring, G. (2000). Mobile RSVP with dynamic
resource sharing. IEEE wireless communications and networking
conference (pp. 896–901).
Marshall, P. S. (2004). Industrial Ethernet. ISA Book. ISBN 1556178697.
Mataix, C., Martin, P., Rodriguez, F.-J., Manzano, M. J., Pozo, J.,
Donato, P. G. (2003). Design and implementation of a safety
communication network in railways with intelligent fault diagnosis.
IEEE conference on emerging technologies and factory automation,
Lisbon (pp. 109–112).
Meindl, A. (2002). Ethernet Powerlink, Application in practice. PRAXIS
profiLine—industrial Ethernet, April 2002 (pp. 55–57).
Miorandi, D., Pitturi, S. (2004). Hybrid wired/wireless implementations
of Profibus DP: A feasibility study based on Ethernet and Bluetooth.
Computer Communications, 27(10), 946–960.
Moon, B., Aghvami, H. (2001). RSVP extensions for real-time services
in wireless mobile networks. IEEE Communications Magazine, 39(12),
52–59.
Naedele, M. (2003). IT security for automation systems, motivations and
mechanisms. Automatisierungstechnische Praxis, 45(5), 84–91.
Naedele, M. (2004). Innovative approaches for security in automation
systems. VDE congress, Berlin (pp. 233–238) (in German).
Naedele, M., Dzung, D., Stanimirov, M. (2001). Network security for
substation automation systems. Computer safety, reliability and
security safecomp 2001. Lecture notes in computer science (Vol. 2187,
pp. 25–34). Berlin: Springer.
Neumann, P. (2002). Merging Fieldbus and telecommunication systems in
the industrial automation domain. Sixth AFRICON conference in
George IEEE AFRICON 2002 (Vol. 1, p. 197).
Neumann, P. (2004). Communication in industrial automation—What is
going on? Keynote speech at the 11th IFAC symposium on information
control problems in manufacturing INCOM’04, Salvador, Brazil.
Neumann, P., Po¨ schmann, A. (2005). Ethernet-based real-time
communication with PROFINET IO. WSEAS Transactions on
Communications, 4(5), 235–245.
Nolte, T., Hansson, H., Lo Bello, L. (2005). Wireless automotive
communications. Fourth international workshop on real-time networks,
Palma de Mallorca Spain, July.
OSF C 706. Open Software Foundation (OSF). C706, CAE specification
DCE11: remote procedure call.
Palensky, P., Sauter, T. (2000). Security considerations for FAN
Internet connections. International workshop on factory communication
systems (pp. 27–35).
Pedreiras, P., Almeida, L. (2005). Approaches to enforce real-time
behavior in Ethernet. In R. Zurawski (Ed.), The industrial commu-
nication technology handbook. Boca Raton, FL: CRC Press.
Pohlmann, T. (2005). Radio technology for CAN networks Workshop on
radio-based communications in industrial automation, Du¨ sseldorf, Mai,
2005 (in German).
Po¨ schmann, A., Werner, T. (2003). Studie Ethernet in der Automation.
Frankfurt: ZVEI (in German).
PROFIBUS Guideline (2002). PROFInet Architecture Description and
Specification. Version 1.9. Karlsruhe: PNO; 2002.
PROFIBUS Guideline (2003). PROFInet Architecture Description and
Specification, Version V 2.0. Karlsruhe: PNO; 2003.
PROFIsafe online (2005). Available at: hhttp://www.profibus.com/
marketingpages/profisafe/i.
Rauchhaupt, L. (1999). Wireless CAN extensions. Sixth international
CAN conference (iCC’99), Turin (pp. 02-07–02-14).
Rauchhaupt, L. (2002). System and device architecture of a radio based
Fieldbus—The RFieldbus system. Fourth IEEE international workshop
on factory communication systems, Va¨ stera˚ s (pp. 185–192).
Rauchhaupt, L. (2003). RFieldbus—a survey. Fifth IFAC international
conference on Fieldbus systems and their applications FET 2003, Aveiro,
Portugal (pp. 105–114).
Rauchhaupt, L., Ha¨ hniche, J. (1999). Opportunities and problems of
wireless Fieldbus extensions. Fieldbus technology; systems integration,
networking, and engineering. Fieldbus conference FeT’99, Magdeburg
(pp. 48–54).
Real-Time Innovations Inc. (2002). Real-time publish-subscribe wire
protocol specification hhttp://www.rti.com/products/literature.htmli.
SafetyBus p online (2005). Available at: hhttp://www.pilz.com/english/
products/safety/bus/concept.htmi.
Scheible, G., Endresen, J., Frey, J. E. (2005). Reliability and
interference resistance as basis of the selection of radio technologies
for factory automation. Workshop on radio-based communications in
industrial automation, Du¨ sseldorf, Mai (in German).
Schneider, B. (2002). Secrets and lies—digital security in a networked
world. New York: Wiley.
Schultz, E. (2002). Security views. Computers Security, 22(5),
368–377.
Schwaiger, C., Treytl, A. (2003). Smart card based security for Fieldbus
systems. IEEE conference on emerging technologies and factory
automation, Lisbon (pp. 398–406).
Song, Y., Koubaa, A., Simonot, F. (2002). Switched Ethernet for real-
time industrial communication: Modelling and message buffering
delay evaluation. Fourth IEEE international workshop on factory
communication systems (WFCS 2002) (pp. 27–35).
Thanikesavan, S., Killat, U. (2004). Global scheduling of periodic tasks
in a decentralised real-time control system. Fifth IEEE international
workshop on factory communication systems WFCS 2004, Vienna
(pp. 307–310).
Treytl, A., Sauter, T., Schwaiger, C. (2004). Security measures for
industrial Fieldbus systems—state of the art and solutions for IP-based
approaches. Fifth IEEE international workshop on factory communica-
tion systems, WFCS 2004, Vienna, Austria (pp. 201–209).
Tseng, C.-C., Lee, G.-C., Liu, R.-S. (2001). HMRSVP: A hierarchical
mobile RSVP protocol. International conference on distributed comput-
ing systems (pp. 467–472).
Wang, J., Ravindran, B. (2004). Time-utility function-driven switched
Ethernet: Packet scheduling algorithm, implementation and feasibility
analysis. IEEE Transactions on Parallel and Distributed Systems,
15(2).
Weczerek, J. (2005). Experience with Bluetooth in industrial applications.
Workshop on radio-based communications in industrial automation,
Du¨ sseldorf, Mai, 2005 (in German).
Willig, A. (2003). Polling-based MAC protocols for improving real-time
performance in a wireless network. IEEE Transactions on Industrial
Electronics, 50(4), 806–817.
Wolframm, M. (2004). What does IPv6 offer regarding the most
important requirements of the automation domain? VDE congress,
Berlin (pp. 175–178) (in German).
ARTICLE IN PRESS

Communication Systems in Industrial Automation

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Communication Systems in Industrial Automation

Similar to Communication Systems in Industrial Automation (20)

More from Tiago Oliveira

More from Tiago Oliveira (14)

Recently uploaded

Recently uploaded (20)

Communication Systems in Industrial Automation