981

Industrial Com56. Industrial Communication Protocols

Carlos E. Pereira, Peter Neumann

This chapter discusses a very relevant aspect inmodern automation systems: the presence ofindustrial communication networks and their pro-tocols. The introduction of Fieldbus systems hasbeen associated with a change of paradigm to de-ploy distributed industrial automation systems,emphasizing device autonomy and decentralizeddecision making and control loops. The chapterpresents the main wired and wireless industrialprotocols used in industrial automation, man-ufacturing, and process control applications. Inorder to help readers to better understand thedifferences between industrial communicationprotocols and protocols used in general computernetworking, the chapter also discusses the spe-cific requirements of industrial applications. As thetrend of future automation systems is to incorpo-rate complex heterogeneous networks, consistingof (partially homogeneous) local and wide area aswell as wired and wireless communication sys-tems, the concept of virtual automation networksis presented

56.1 Basic Information ................................. 98156.1.1 History ...................................... 98156.1.2 Classification ............................. 98256.1.3 Requirements in Industrial

Automation Networks ................. 98256.1.4 Chapter Overview ....................... 982

56.2 Virtual Automation Networks ................. 98356.2.1 Definition, Characterization,

Architectures ............................. 98356.2.2 Domains ................................... 98356.2.3 Interfaces, Network Transitions,

Transmission Technologies .......... 984

56.3 Wired Industrial Communications .......... 98456.3.1 Introduction .............................. 98456.3.2 Sensor/Actuator Networks............ 98556.3.3 Fieldbus Systems ........................ 98656.3.4 Controller Networks .................... 988

56.4 Wireless Industrial Communications ....... 99156.4.1 Basic Standards ......................... 99156.4.2 Wireless Local Area Networks

(WLAN) ...................................... 99256.4.3 Wireless Sensor/Actuator

Networks .................................. 992

56.5 Wide Area Communications ................... 993

56.6 Conclusions .......................................... 995

56.7 Emerging Trends .................................. 995

56.8 Further Reading ................................... 99756.8.1 Books ....................................... 99756.8.2 Various Communication

Standards ................................. 99756.8.3 Various web Sites

of Fieldbus Organizationsand Wireless Alliances ................ 997

References .................................................. 998

56.1 Basic Information

56.1.1 History

Digital communication is now well established in dis-tributed computer control systems both in discretemanufacturing as well as in the process control in-dustries. Proprietary communication systems within

SCADA (supervisory control and data acquisition) sys-tems have been supplemented and partially displacedby Fieldbus and sensor bus systems. The introductionof Fieldbus systems has been associated with a changeof paradigm to deploy distributed industrial automationsystems, emphasizing device autonomy and decentral-

PartF

56

982 Part F Industrial Automation

ized decision making and control loops. Nowadays,(wired) Fieldbus systems are standardized and are themost important communication systems used in com-mercial control installations. At the same time, Ethernetwon the battle as the most commonly used communi-cation technology within the office domain, resulting inlow component prices caused by mass production. Thishas led to an increasing interest in adapting Ethernetfor industrial applications and several approaches havebeen proposed (Sect. 56.1.4). Ethernet-based solutionsare dominating as a merging technology.

In parallel to advances on Ethernet-based industrialprotocols, the use of wireless technologies in the in-dustrial domain has also been increasingly researched.Following the trend to merge automation and officenetworks, heterogeneous networks (virtual automationnetworks (VAN)), consisting of local and wide area net-works, as well as wired and wireless communicationsystems, are becoming important [56.1].

56.1.2 Classification

Industrial communication systems can be classified asfollows regarding different capabilities:

• Real-time behavior: Within the automation domain,real-time requirements are of uttermost importanceand are focused on the response time behavior ofdata packets. Three real-time classes can be identi-fied based on the required temporal behavior:– Class 1: soft real-time. Scalable cycle time, used

in factory floor and process automation in caseswhere no severe problems occur when deadlinesare not met.

– Class 2: hard real-time. Typical cycle times from1 to 10 ms, used for time-critical closed loopcontrol.

– Class 3: isochronous real-time, cycle times from250 μs to 1 ms, with tight restrictions on jitter(usually less than 1 μs), used for motion controlapplications.

Additionally, there is a class non real-time, whichmeans systems without real-time requirements;these are not considered here. It means (regardingindustrial automation) exchange of engineering datamaintenance, etc.• Distribution: The most important achievementof industrial communication systems are localarea communication systems, consisting of sen-sor/actuator networks (Chap. 20 and Sect. 56.3.2),Fieldbus systems, and Ethernet-based local area net-

works (LAN). Of increasing importance is the useof wide area networks (WAN) (telecommunicationnetworks, Internet, etc.). Thus, it should be advan-tageous to consider WANs as part of an industrialcommunication system (Sect. 56.2), mostly withinthe upper layers of an enterprise hierarchy.• Homogeneity: There are homogeneous parts (e.g.standardized Fieldbus systems) within an industrialcommunication system. But in real applications theuse of heterogeneous networks is more common,especially when using WANs and when connectedwith services of network providers.• Installations types: While most of the installed en-terprise networks are currently wired, the numberof wireless installations is increasing and this trendwill continue.

56.1.3 Requirements in IndustrialAutomation Networks

The main requirements are:

• Real-time behavior: Diagnosis, maintenance, com-missioning, and slow mobile applications areexamples of non real-time applications. Processautomation and data acquisition usually presentsoft real-time requirements. Examples of hardreal-time applications are closed-loop control ap-plications, such as in fast mobile applications andmachine tools. Motion control is an example of anisochronous hard real-time application.• Functional safety: Protection against hazards causedby incorrect functioning including communica-tion via heterogeneous networks. There are severalsafety integrity levels (SIL) [56.2]. It includes theinfluence of noisy environments and the degree ofreliability.• Security: This means a common security conceptfor distributed automation using a heterogeneousnetwork with different security integrity levels (notexistent yet).• Location awareness: The desired context awarenessleads to the usage of location-based communicationservices and context-sensitive applications.

56.1.4 Chapter Overview

The remainder of the chapter is structured as follows.Section 56.2 discusses the concept of virtual automationnetworks (VANs), a key concept in future distributedautomation systems, which will be composed of (par-tially homogeneous) local and wide area as well as

PartF

56.1

Industrial Communication Protocols 56.2 Virtual Automation Networks 983

wired and wireless communication systems leading tocomplex heterogenous communication networks.

In Sect. 56.3 the main wired industrial communi-cation protocols are presented and compared, while

Sect. 56.4 discusses wireless industrial communicationsystems. Section 56.5 deals with the use of wide areacommunications to execute remote automation opera-tions.

56.2 Virtual Automation Networks

56.2.1 Definition, Characterization,Architectures

Future scenarios of distributed automation lead todesired mechanisms for geographically distributed au-tomation functions for various reasons:

• Centralized supervision and control of (many) de-centralized (small) technological plants• Remote control, commissioning, parameterization,and maintenance of distributed automation systems• Inclusion of remote experts or external machine-readable knowledge for plant operation and main-tenance (for example, asset management, conditionmonitoring, etc.).

This means that heterogeneous networks, consist-ing of (partially homogeneous) local and wide ar-eas, as well as wired and wireless communicationsystems, will play an increasing role. Figure 56.1

Industrial domain

Industrial segment

Domain connectedvia radio link Public and private

telecommunicationnetworks/internet

ain

IndustVA

N d

omai

n A

onnecteddio link

VAN domain B

nt

Public and privatetelecommunicatinetworks/inte

VAN domain C

Intrinsic safetydomain

Office sub domains

Office domain

Individual industrial sub domains

Remark:All systems are shown generally as a bus. Depending on the real systemit may be any type of topology including a ring.

Real-time domain

Single device integration(e.g. tele control)

Industrial WLAN domain

Industrial backbone

Mobile devicesIndustrialWLAN domain

Real-time domain Mobile devices

Remote industrial domains / subsidiary / customer sites

Fig. 56.1 Different VAN domains related to different automation applications [56.3]

depicts the communication environment of a com-plex automation scenario. Following a unique designconcept, regarding the objects to be transmitted be-tween geographically distributed communication endpoints, the heterogeneous network becomes a virtualautomation network (VAN) [56.3, 4]. VAN charac-teristics are defined for domains, where the expres-sion domain is widely used to address areas anddevices with common properties/behavior, commonnetwork technology, or common application pur-poses.

56.2.2 Domains

Within the overall automation and communication en-vironment, a VAN domain covers all devices that aregrouped together on a logical or virtual basis to rep-resent a complex application such as an industrialapplication. Therefore, the encompassed networks maybe heterogeneous and devices can be geographically

PartF

56.2

984 Part F Industrial Automation

W/WLlink

W/WLlink

WLdevice

WLdevice

WLdevice

WLdevice

MANstation

WAN,Internet

DeviceCon-troller

Super-visor

Internetserver

Officedevice

Managerstation

Telecommunication

LAN

RTE

Fieldbus Wirelessfieldbus

Proxygateway

Fig. 56.2 Network transitions (local area networks (LAN), wire-less LAN (WL), wired/wireless (W/WL), real-time Ethernet (RTE),metropolitan area network (MAN), wide area network (WAN))

distributed over a physical environment, which shallbe covered by the overall application. But all de-vices that have to exchange information within thescope of the application (equal to a VAN domain)must be VAN aware or VAN enabled devices. Other-wise, they are VAN independent and are not a memberof a VAN domain. Figure 56.1 depicts VAN domainexamples representing three different distributed appli-cations.

Devices related to a VAN domain may reside ina homogeneous network domain (e.g. the industrialdomain shown in Fig. 56.1). But, depending on the ap-plication, additional VAN relevant devices may only bereached by crossing other network types (e.g., wide areanetwork type communication) or they need to use proxytechnology to be represented in the VAN domain viewof a complex application.

56.2.3 Interfaces, Network Transitions,Transmission Technologies

A VAN network consists of several different com-munication paths and network transitions. Figure 56.2depicts the required transitions in heterogeneous net-works.

Depending on the network and communicationtechnology of the single path there will be differencesin the addressing concept of the connected network seg-ments. Also the communication paths have differentcommunication line properties and capabilities. There-fore, for the path of two connected devices withina VAN domain the following views are possible:

• The logical view: describing the properties/capabili-ties of the whole communication path• The physical view: describing the detailed proper-ties/capabilities of the passed technology-dependentcommunication paths• The behavioral view: describing the differentcyclic/acyclic temporal behavior of the passed seg-ments.

There are different opportunities to achieve a com-munication path between network segments/devices(or their combinations). These are: Ethernet line(with/without transparent communication devices),wireless path, telecommunication network (1:1), publicnetworks (n:m, provider-oriented), VPN tunnel, gate-way (without application data mapping), proxy (withapplication data mapping), VAN access point, and IPmapping. All networks, which can not be connected viaan IP-based communication stack, must be connectedusing a proxy. For connecting nonnested/cascaded VANsubdomains via public networks the last solution (VANaccess point) should be preferred.

56.3 Wired Industrial Communications

56.3.1 Introduction

Wired digital communication has been an importantdriving force of computer control systems for the last30 years. To allow the access to data in various layersof an enterprise information system by different users,there is a need to merge different digital communica-tion systems within the plant, control, and device levelsof an enterprise network. On these different levels, thereare distinct requirements dictated by the nature and type

of information being exchanged. Network physical size,number of supported devices, network bandwidth, re-sponse time, sampling frequency, and payload size aresome of the performance characteristics used to clas-sify and group specific network technologies. Real-timerequirements depend on the type of messages to be ex-changed: deadlines for end-to-end data transmission,maximum allowed jitter for audio and video streamtransmission, etc. Additionally, available resources atthe various network levels may vary significantly. At

PartF

56.3

Industrial Communication Protocols 56.3 Wired Industrial Communications 985

the device level, there are extremely limited resources(hardware, communications), but at the plant levelpowerful computers allow comfortable software andmemory consumption.

Due to the different requirements described above,there are different types of industrial communicationsystems as part of a hierarchical automation systemwithin an enterprise:

• Sensor/actuator networks: at the field (sensor/actu-ator) level• Fieldbus systems: at the field level, collect-ing/distributing process data from/to sensors/actua-tors, communication medium between field devicesand controllers/PLCs/management consoles• Controller networks: at the controller level, trans-mitting data between powerful field devices andcontrollers as well as between controllers• Wide area networks: at the enterprise level, connect-ing networked segments of an enterprise automationsystem.

Vendors of industrial communication systems offera set of fitting solutions for these levels of the automa-tion/communication hierarchy.

56.3.2 Sensor/Actuator Networks

At this level, several well established and widelyadopted protocols are available:

• HART (HART Communication Foundation): high-way addressable remote transducer, coupling analogprocess devices with engineering tools [56.5]• ASi (ASi Club): actuator sensor interface, couplingbinary sensors in factory automation with controldevices [56.6].

Additionally, CAN-based solutions (CAN in au-tomation (CIA)) are used for wide-spread applicationfields, coupling decentralized devices with centralizeddevices based on physical and MAC layers of thecontroller area network [56.7]. Recently, IO Link hasbeen specified for bi-directional digital transmission ofparameters between simple sensor/actuator devices infactory automation [56.8, 9].

HARTHART Communication [56.5] is a protocol specifi-cation, which performs a bi-directional digital trans-mission of parameters (used for configuration andparameterization of intelligent field instruments bya host system) over analog transmission lines. The host

Power supply

Resistor(250 Ohm)

Field device

Handheld terminal

PChost application

HART interface(RS 232 or USB)

Fig. 56.3 A HART system with two masters(http://www.hartcomm.org)

system may be a distributed control system (DCS),a programmable logic controller (PLC), an asset man-agement system, a safety system, or a handheld device.HART technology is easy to use and very reliable.The HART protocol uses the Bell 202 Frequency ShiftKeying (FSK) standard to superimpose digital commu-nication signals at a low level on top of the 4–20 mAanalog signal. The HART protocol communicates at1200 bps without interrupting the 4–20 mA signal andallows a host application (master) to get two or moredigital updates per second from a field device. As thedigital FSK signal is phase continuous, there is no inter-ference with the 4–20 mA signal. The HART protocolpermits all digital communication with field devices ineither point-to-point or multidrop network configura-tions. HART provides for up to two masters (primaryand secondary). As depicted in Fig. 56.3, this allowssecondary masters (such as handheld communicators)to be used without interfering with communicationsto/from the primary master (i. e. control/monitoring sys-tem).

ASi (IEC 62026-2)ASi [56.6] is a network of actuators and sensors (op-tical, inductive, capacitive) with binary input/outputsignals. An unshielded twisted pair cable for data andpower (max. 2 A; max. 100 m) enables the connectionof 31 slaves (max. 124 binary signals of sensors and/oractuators). This enables a modular design using anynetwork topology (i. e. bus, star, tree). Each slave canreceive any available address and be connected to thecable at any location.

AS-Interface uses the APM method (alternatingpulse modulation) for data transfer. The medium access

PartF

56.3

986 Part F Industrial Automation

is controlled by a master–slave principle with cyclicpolling of all nodes. ASi masters are embedded (ASi)communication controllers of PLCs or PCs, as well asgateways to other Fieldbus systems. To connect legacysensors and actuators to the transmission line, variouscoupling modules are used. AS-Interface messages canbe classified as follows:

• Single transactions: maximum of 4 bit informationtransmitted from master to slave (output informa-tion) and from slave to master (input information)• Combined transactions: more than 4 bits of coherentinformation are transmitted, composed of a series ofmaster calls and slave replies in a defined context.

For more details see www.as-interface.com.

56.3.3 Fieldbus Systems

Nowadays, Fieldbus systems are standardized (thoughunfortunately not unified) and widely used in in-dustrial automation. The IEC 61158 and 61784standards [56.11, 12] contain ten different Fieldbusconcepts. Seven of these concepts have their own com-plete protocol suite: PROFIBUS (Siemens, PROFIBUSInternational); Interbus (Phoenix Contact, InterbusClub); Foundation Fieldbus H1 (Emerson, FieldbusFoundation); SwiftNet (B. Crowder); P-Net (ProcessData); and WorldFIP (Schneider, WorldFIP). Threeof them are based on Ethernet functionality: highspeed Ethernet (HSE) (Emerson, Fieldbus Foundation);Ethernet/IP (Rockwell, ODVA); PROFINET/CBA:(Siemens, PROFIBUS International). The world-wide

Slave 2 Slave 3Slave 3

Cyclic dataexchange

Configurationparameteriz.

Slave 1

Cyclic access of master 1 Acyclic access of master 2

Cycle

PROFIBUS-DPMaster class 1

PROFIBUS-DPMaster class 2

DP-slave 1 DP-slave 2

Token

DP-slave 3

Fig. 56.4 Profibus medium access control (from [56.10])

leading positions within the automation domain re-garding the number of installed Fieldbus nodes holdPROFIBUS and Interbus followed by DeviceNet (Rock-well, ODVA), which has not been part of the IEC61158 standard. For that reason, the basic conceptsof PROFIBUS and DeviceNet will be explained verybriefly. Readers interested in a more comprehensive de-scription are referred to the related web sites.

PROFIBUSPROFIBUS is a universal fieldbus for plantwide useacross all sectors of the manufacturing and processindustries based on the IEC 61158 and IEC 61784standards. Different transmission technologies are sup-ported [56.10]:

• RS 485: Type of medium attachment unit (MAU)corresponding to [56.13]. Suited mainly for factoryautomation. Technical details see [56.10, 13]. Num-ber of stations: 32 (master stations, slave stationsor repeaters); Data rates: 9.6/19.2/45.45/93.75/

187.5/500/1500/3000/6000/12 000 kb/s.• Manchester bus powered (MBP). Type of MAUsuited for process automation: line, tree, and startopology with two wire transmission; 31.25 kBd(preferred), high speed variants w/o bus power-ing and intrinsic safety; synchronous transmission(Manchester encoding); optional: bus powered de-vices (≥ 10 mA per device; low power option);optional: intrinsic safety (Ex-i) via additional con-straints according to the FISCO model. Intrinsicsafety means a type of protection in which a portionof the electrical system contains only intrinsicallysafe equipment (apparatus, circuits, and wiring)that is incapable of causing ignition in the sur-rounding atmosphere. No single device or wiringis intrinsically safe by itself (except for battery-operated self-contained apparatus such as portablepagers, transceivers, gas detectors, etc., whichare specifically designed as intrinsically safe self-contained devices) but is intrinsically safe onlywhen employed in properly designed intrinsicallysafe system. There are couplers/link devices to cou-ple MBP and RS485 transmission technologies.• Fibre optics (not explained here, see [56.10]).

There are two medium access control (MAC) mech-anisms (Fig. 56.4):

1. Master–master traffic using token passing2. Master–slave traffic using polling.

PartF

56.3

Industrial Communication Protocols 56.3 Wired Industrial Communications 987

PROFIBUS differentiates between two types ofmasters:

1. Master class 1, which is basically a central con-troller that cyclically exchanges information withthe distributed stations (slaves) at a specified mes-sage cycle.

2. Master class 2, which are engineering, config-uration, or operating devices. The slave-to-slavecommunication is based on the application modelpublisher/subscriber using the same MAC mecha-nisms.

The dominating PROFIBUS protocol is the applica-tion protocol DP (decentralized periphery), embeddedinto the protocol suite (Fig. 56.5).

Depending upon the functionality of the masters,there are different volumes of DP specifications. Thereare various profiles, which are grouped as follows:

1. Common application profiles (regarding functionalsafety, synchronization, redundancy etc.)

2. Application field specific profiles (e.g. processautomation, semiconductor industries, motion con-trol).

These profiles reflect the broad experience of thePROFIBUS International organization.

DeviceNetDeviceNet is a digital, multi-drop network that connectsand serves as a communication network between in-dustrial controllers and I/O devices. Each device and/orcontroller is a node on the network. DeviceNet usesa trunk-line/drop-line topology that provides separatetwisted pair busses for both signal and power distribu-tion. The possible variants of this topology are shownin [56.14].

Thick or thin cables can be used for either trunk-lines or droplines. The maximum end-to-end networklength varies with data rate and cable thickness. De-viceNet allows transmission of the necessary power onthe network. This allows devices with limited powerrequirements to be powered directly from the net-work, reducing connection points and physical size.DeviceNet systems can be configured to operate ina master-slave or a distributed control architecture us-ing peer-to-peer communication. At the applicationlayer, DeviceNet uses a producer/consumer applicationmodel. DeviceNet systems offer a single point of con-nection for configuration and control by supporting bothI/O and explicit messaging.

DeviceNet uses CAN (controller area network[56.7]) for its data link layer, and CIP (common indus-

PROFIBUS DP

PA d

evic

es

RIO

for

PA

SEM

I ...

PRO

FIdr

ive

Iden

t sys

tem

s

Wei

ghin

g&

dos

ing

Enc

oder

IEC 61158/61784

DP-V0...V2

RS 485: NRZRS 485-ISIntrinsic safety

Fiber optics: GlassSingle/Multi mode;PCF/Plastic fiber

MBP: Manchester BusPowered (LP: Low power,IS: Intrinsic safety

Applicationprofiles II

Applicationprofiles I

Communic.technologies

Transmissiontechnologies

Des

crip

tions

(G

SD, E

DD

)to

ols

(DT

M, C

onfi

gura

tors

)

Mas

ter

conf

orm

. cla

sses

inte

rfac

es, C

onst

rain

ts

Inte

grat

ion

tech

nolo

gies

Syst

empr

ofile

s 1.

.. , x

Common application profiles (optional)

PROFIsafe, Time stamp, Redundancy, etc.

Fig. 56.5 PROFIBUS protocol suite (from [56.10])

trial protocol) for the upper network layers. As with allCIP networks, DeviceNet implements CIP at the ses-sion (i. e. data management services) layer and above,and adapts CIP to the specific DeviceNet technology atthe network and transport layer, and below. Figure 56.6depicts the DeviceNet protocol suite.

The data link layer is defined by the CAN speci-fication and by the implementation of CAN controllerchips. The CAN specification [56.7] defines two busstates called dominant (logic 0) and recessive (logic1). Any transmitter can drive the bus to a domi-nant state. The bus can only be in the recessive statewhen no transmitter is in the dominant state. A con-nection with a device must first be established inorder to exchange information with that device. Toestablish a connection, each DeviceNet node will imple-ment either an unconnected message manager (UCMM)

CIP common industrialprotocol (IEC 61158)

DeviceNet specification(IEC 62026)

ADevice profiles

& application objects

Connection manager

DeviceNet specification(IEC 62026)

CAN specification(ISO 11898)

Peer-to-peer, Master-slave,Multi-master, 64 nodes/network

Controller area network (CAN)

P

T

N

DL

PHY

S

Explicitmessaging

Implicitmessaging

Fig. 56.6 DeviceNet protocol suite (from [56.14])

PartF

56.3

988 Part F Industrial Automation

or a Group 2 unconnected port. Both perform theirfunction by reserving some of the available CANidentifiers. When either the UCMM or the Group 2unconnected port is selected to establish an explicitmessaging connection, that connection is then used tomove information from one node to the other (usinga publisher/subscriber application model), or to estab-lish additional I/O connections. Once I/O connectionshave been established, I/O data may be moved amongdevices on the network.

At this point, all the protocol variants of the De-viceNet I/O message are contained within the 11 bitCAN identifier. CIP is strictly object oriented. Eachobject has attributes (data), services (commands), andbehavior (reaction to events). Two different types ofobjects are defined in the CIP specification: com-munication objects and application-specific objects.Vendor-specific objects can also be defined by vendorsfor situations where a product requires functionalitythat is not in the specification. For a given device type,a minimum set of common objects will be implemented.

An important advantage of using CIP is that forother CIP-based networks the application data remainsthe same regardless of which network hosts the de-vice. The application programmer does not even needto know to which network a device is connected.

CIP also defines device profiles, which identifies theminimum set of objects, configuration options, and theI/O data formats for different types of devices. Devicesthat follow one of the standard profiles will have thesame I/O data and configuration options, will respondto all the same commands, and will have the same be-havior as other devices that follow that same profile. Formore information on DeviceNet readers are referred towww.odva.org.

56.3.4 Controller Networks

This network class requires powerful communicationtechnology. Considering controller networks based onEthernet technology, one can distinguish between (re-lated to the real-time classes, see Sect. 56.1):

1. Local soft real-time approaches (real-time class 1)2. Deterministic real-time approaches (real-time

class 2)3. Isochronous real-time approaches (real-time

class 3).

The standardization process started in 2004. Therewere many candidates to become part of the ex-tended Fieldbus standard IEC 61158 (edition 4): high

speed Ethernet HSE (Emerson, Fieldbus Foundation);Ethernet/IP (Rockwell, ODVA); and PROFINET/CBA(Siemens, PROFIBUS International). Nine Ethernet-based solutions have been added. In this section a shortsurvey of the previously mentioned real-time classeswill be given, and two practical examples will be ex-amined.

Local Soft Real-Time Approaches(Real-Time Class 1)

These approaches use TCP (UDP)/IP mechanisms overshared and/or switched Ethernet networks. They canbe distinguished by different functionalities on top ofTCP (UDP)/IP, as well as by their object models andapplication process mechanisms. Protocols based onEthernet-TCP/IP offer response times in the lower mil-lisecond range but are not deterministic, since datatransmission is based on the best effort principle. Someexamples are given below.

MODBUS TCP/IP (Schneider) [56.15]. MODBUS is anapplication layer messaging protocol for client/servercommunication between devices connected via differ-ent types of buses or networks. Using Ethernet as thetransmission technology, the application layer proto-col data unit (A-PDU) of MODBUS (function codeand data) is encapsulated into an Ethernet frame. Theconnection management on top of TCP/IP controls theaccess to TCP.

Ethernet/IP (Rockwell, ControlNet International, OpenDeviceNet Vendor Association) uses a common in-dustrial protocol CIP [56.16]. In this context, IP standsfor industrial protocol (not for Internet protocol). CIPrepresents a common application layer for all physi-cal networks of Ethernet/IP, ControlNet and DeviceNet.Data packets are transmitted via a CIP router betweenthe networks. For the real-time I/O data transfer, CIPworks on top of UDP/IP. For the explicit messaging,CIP works on top of TCP/IP. The application process isbased on a producer/consumer model.

High Speed Ethernet HSE (Fieldbus Foundation)[56.17]. A field device agent represents a specific Field-bus Foundation application layer function (includingFieldbus message specification). Additionally, there areHSE communication profiles to support the differentdevice categories: host device, linking device, I/O gate-way, and field device. These devices share the tasksof the system using distributed function block applica-tions.

PartF

56.3

Industrial Communication Protocols 56.3 Wired Industrial Communications 989

PROFINET (PNO PROFIBUS User Organization, Siemens)[56.19]. uses object model CBA (component based ar-chitecture) and DCOM wire protocol with the remoteprocedure call mechanisms (DCE RPC) (OSF C 706)to transmit the soft real-time data. An open source codeand various exemplary implementations/portations fordifferent operating systems are available on the PNOweb site.

P-Net on IP (Process Data) [56.20]. Based on P-NetFieldbus standard IEC 61158 Type 4 [56.11], P-Net onIP contains the mechanism to use P-Net in an IP en-vironment. Therefore, P-Net PDUs are wrapped intoUDP/IP packages, which can be routed through IP net-works. Nodes on the IP network are addressed with twoP-Net route elements. P-Net clients (master) can ac-cess servers on an IP network without knowing anythingabout IP addresses.

All of the above mentioned approaches are ableto support widely used office domain protocols, suchas SMTP, SNMP, and HTTP. Some of the approachessupport BOOTP and DHCP for web access and/or forengineering data exchange. But the object models of theapproaches differ.

Deterministic Real-Time Approaches(Real-Time Class 2)

These approaches use a middleware on top of theMAC layer to implement scheduling and smoothingfunctions. The middleware is normally represented bya software implementation. Industrial examples includethe following.

PROFINET (PROFIBUS International, Siemens) [56.19].This variant of the Ethernet-based PROFINET IO sys-tem (using the main application model background ofthe Fieldbus PROFIBUS DP) uses the object modelIO (input/output). Figure 56.7 roughly depicts thePROFINET protocol suite, containing the connectionestablishment for PROFINET/CBA via connection-oriented RPC on the left side, as well as for thePROFINET IO via connectionless RPC on the rightside. The exchange of (mostly cyclic) productive datauses the real-time functions in the center.

The PROFINET IO service definition and pro-tocol specification [56.21] covers the communicationbetween programmable logical controllers (PLCs), su-pervisory systems, and field devices or remote inputand output devices. The PROFINET IO specificationcomplies with IEC 61158, Parts 5 and 6, specially theFieldbus application layer (FAL). The PROFINET pro-

Component contextmanagement (ACCO)

DCOM

CO-RPC

TCP

IP

CL-RPC

UDP

IP

Component object model

IO contextmanagement

IEEE 802.3

Real-time

Cyclic(producer/consumer)and acyclic services

Connectionestablishment

Connectionestablishment

IO object model

Fig. 56.7 PROFINET protocol suite of PROFINET (from [56.18])(active control connection object (ACCO), connection-oriented(CO), connectionless (CL), remote procedure call (RPC))

tocol is defined by a set of protocol machines. For moredetails see [56.22].

Time-Critical Control Network (Tcnet, Toshiba) [56.23].Tcnet specifies in the application layer a so-called com-mon memory for time-critical applications, and usesthe same mechanisms as mentioned for PROFINET IOfor TCP(UDP)/IP-based non real-time applications. Anextended data link layer contains the scheduling func-tionality. The common memory is a virtual memoryglobally shared by participating nodes as well as ap-plication processes running on each node. It providesa temporal and spatial coherence of data distribution.The common memory is divided into blocks withseveral memory lengths. Each block is transmittedto member nodes using multicast services, supportedby a publisher node. A cyclic broadcast transmissionmechanism is responsible for refreshing the data blocks.Therefore, the common memory consists of dedicatedareas for the transmitting data to be refreshed in eachnode. Thus, the application program of a node has quickaccess to all (distributed) data.

The application layer protocol (FAL) consists ofthree protocol machines: the FAL service protocol ma-chine (FSPM), the application relationship protocolmachine (ARPM), and the data link mapping protocolmachine (DMPM). The scheduling mechanism in thedata link layer follows a token passing mechanism.

Vnet (Yokogawa) [56.24]. Vnet supports up to 254subnetworks with up to 254 nodes each. In its applica-

PartF

56.3

990 Part F Industrial Automation

tion layer, three kinds of application data transfers aresupported:

• A one-way communication path used by an end-point for inputs or outputs (conveyance paths)• A trigger policy• Data transfer using a buffer model or a queue model(conveyance policy).

The application layer FAL contains three types of proto-col machines: the FSPM FAL service protocol machine,ARPMs application relationship protocol machines, andthe DMPM data link layer mapping protocol machine.For real-time data transfer, the data link layer offersthree services:

1. Connection-less DL service2. DL-SAP management service3. DL management service.

Real-time and non real-time traffic scheduling is lo-cated on top of the MAC layer. Therefore, one or moretime-slots can be used within a macro-cycle (depend-ing on the service subtype). The data can be orderedby four priorities: urgent, high, normal, time-available.Each node has its own synchronized macro-cycle. Thedata link layer is responsible for clock synchronization.

Isochronous Real-Time Approaches(Real-Time Class 3)

The main examples are as follows.

Powerlink (Ethernet PowerLink StandardizationGroup (EPSG), Bernecker and Rainer), developedfor motion control [56.25]. Powerlink offers twomodes: protected mode and open mode. The protectedmode uses a proprietary (B&R) real-time protocolon top of the shared Ethernet for protected subnet-works. These subnetworks can be connected to an openstandard network via a router. Within the protectedsubnetwork the nodes cyclically exchange real-timedata avoiding collisions. The scheduling mechanismis a time-division scheme. Every node uses its owntime slot [slot communication network management(SCNM)] to send its data. The mechanism uses a man-ager node, which acts comparably with a bus master,and managed nodes act similar to a slave. This mecha-nism avoids Ethernet collisions. The Powerlink protocoltransfers the real-time data isochronously. The openmode can be used for TCP(UDP)/IP based applications.The network normally uses switches. The traffic hasto be transmitted within an asynchronous period of thecycle.

EtherCAT [EtherCAT Technology Group (ETG), Beckhoff]developed as a fast backplane communication sys-tem [56.26]. EtherCAT distinguishes two modes: directmode and open mode. Using the direct mode, a mas-ter device uses a standard Ethernet port between theEthernet master and an EtherCAT segment. EtherCATuses a ring topology within the segment. The mediumaccess control adopts the master/slave principle, wherethe master node (typically the control system) sends theEthernet frame to the slave nodes (Ethernet device). Onesingle Ethernet device is the head node of an Ether-CAT segment consisting of a large number of EtherCATslaves with their own transmission technology. The Eth-ernet MAC address of the first node of a segment isused for addressing the EtherCAT segment. For the seg-ment, special hardware can be used. The Ethernet framepasses each node. Each node identifies its subframe andreceives/sends the suitable information using that sub-frame. Within the EtherCAT segment, the EtherCATslave devices extract data from and insert data into theseframes. Using the open mode, one or several Ether-CAT segments can be connected via switches with oneor more master devices and Ethernet-based basic slavedevices.

PROFINET IO/Isochronous Technology (PROFIBUS UserOrganization, Siemens) developed for any indus-trial application [56.27]. PROFINET IO/IsochronousTechnology uses a middleware on top of the EthernetMAC layer to enable high-performance transfers, cyclicdata exchange and event-controlled signal transmission.The layer 7 functionality is directly linked to the mid-dleware. The middleware itself contains the schedulingand smoothing functions. This means that TCP/IP doesnot influence the PDU structure. A special Ethertype isused to identify real-time PDUs (only one PDU type forreal-time communication). This enables easy hardwaresupport for the real-time PDUs. The technical back-ground is a 100 Mbps full duplex Ethernet (switchedEthernet). PROFINET IO adds an isochronous real-timechannel to the RT channels of real-time class 2 op-tion channels. This channel enables a high-performancetransfer of cyclic data in an isochronous mode [56.28].Time synchronization and node scheduling mechanismsare located within and on top of the Ethernet MAClayer. The offered bandwidth is separated for cyclic hardreal-time and soft/non real-time traffic. This means thatwithin a cycle there are separate time domains for cyclichard real-time, for soft/non real-time over TCP/IP traf-fic, and for the synchronization mechanism, see alsoFig. 56.8.

PartF

56.3

Industrial Communication Protocols 56.4 Wireless Industrial Communications 991

cRTaRTcRT non RT aRT non RT

31.25 µs ≤ Tsendclock ≤ 4 ms

T60%

tsendclock+1tsendclock

Fig. 56.8 LMPM MAC access used in PROFINETIO [56.22] (cyclic real-time (cRT), acyclic real-time (aRT),nonreal-time (non RT), medium access control (MAC),link layer mapping protocol machine (LMPM))

The cycle time should be in the range of 250 μs(35 nodes) up to 1 ms (150 nodes) when simultane-ously TCP/IP traffic of about 6 Mbps is transmitted. Thejitter will be less than 1 μs. PROFINET IO/IRT usesswitched Ethernet (full duplex). Special four-port andtwo-port switch ASICs have been developed and allowthe integration of the switches into the devices (nodes)substituting the legacy communication controllers ofFieldbus systems. Distances of 100 m per segment(electrical) and 3 km per segment (fiber-optical) can bebridged.

Ethernet/IP with Time Synchronization (ODVA, Rock-well Automation). Ethernet/IP with time synchroniza-tion [56.29], an extension of Ethernet/IP, uses the CIPSynch protocol to enable the isochronous data trans-

fer. Since the CIP Synch protocol is fully compatiblewith standard Ethernet, additional devices without CIPSynch features can be used in the same Ethernet sys-tem. The CIP Synch protocol uses the precision clocksynchronization protocol [56.30] to synchronize thenode clocks using an additional hardware function.CIP Synch can deliver a time-synchronization accuracyof less than 500 ns between devices, which meets therequirements of the most demanding real-time applica-tions. The jitter between master and slave clocks can beless than 200 ns.

SERCOS III, (IG SERCOS Interface e.V.). A SERCOSnetwork [56.31], developed for motion control, con-sists of masters and slaves. Slaves contain integratedrepeaters, which have a constant delay time Trep (in-put/output). The nodes are connected via point-to-pointtransmission lines. Each node (participant) has twocommunication ports, which are interchangeable. Thetopology can be either a ring or a line structure. Thering structure consists of a primary and a secondarychannel. All slaves work in forwarding mode. The re-dundancy provided by the ring structure prevents anydowntime caused by a broken cable. The line structureconsists of either a primary or a secondary channel.The last physical slave performs the loopback func-tion. All other slaves work in forwarding mode. Noredundancy against cable breakage is achieved. It isalso possible to insert and remove slaves during oper-ation (hot plug). This is restricted to the last physicalslave.

56.4 Wireless Industrial Communications

56.4.1 Basic Standards

Wireless communication networks are increasinglypenetrating the application area of wired communica-tion systems. Therefore, they have been faced with therequirements of industrial automation. Wireless tech-nology has been introduced in automation as wirelesslocal area networks (WLAN) and wireless personalarea networks (WPAN). Currently, the wireless sensornetworks (WSN) are under discussion especially forprocess automation. For specific application aspects ofwireless communications see Chap. 13 on Communica-tion in Automation, Including Networking and Wireless,and Chap. 20 on Sensors and Sensor Networks. The ba-sic standards are the following:

• Mobile communications standards: GSM, GPRS,and UMTS wireless telephones (DECT)• Lower layer standards (IEEE 802.11: WirelessLAN [56.32], and 802.15 [56.33]: personal areanetworks) as a basis of radio-based local networks(WLANs, Pico networks and sensor/actuator net-works)• Higher layer standards (application layers on topof IEEE 802.11 and 802.15.4, e.g. WiFi, blue-tooth [56.34], wireless HART, and ZigBee [56.35])• Proprietary protocols for radio technologies (e.g.wireless interface for sensors and actuators (WISA)[56.36])• Upcoming radio technologies such as ultra wideband (UWB) and WiMedia

PartF

56.4

992 Part F Industrial Automation

For more detailed information and survey see [56.37–41].

56.4.2 Wireless Local Area Networks (WLAN)

The term WLAN refers to a wireless version of the Eth-ernet used to build computer networks for office andhome applications. The original standard (IEEE802.11)specified an infrared, a direct sequence spread spec-trum (DSSS) and a frequency hopping spread spectrum(FHSS) physical layer. There is an approval for WLANto use special frequency bands, however it has toshare the medium with other users. The WiFi Alliancewas founded to assure interoperability between WLANclients and access points of different vendors. There-fore, a certification procedure and a WiFi logo areprovided. WLANs use a licence-free frequency bandand no service provider is necessary.

WLAN is a mature technology and it is imple-mented in PCs, laptops, and PDAs. Modules for em-bedded systems development are also available. WLANcan be used almost world wide. Embedded WLAN de-vices need a powerful microcontroller. WLAN enableswireless access to Ethernet based LANs and is helpfulfor the vertical integration in an automated manufactur-ing environment. It offers high speed data transmissionthat can be used to transmit productive data and man-agement data in parallel. The WLAN propagationcharacteristics fit into a number of possible automationapplications. WLAN enables more flexibility and a costeffective installation in automation associated with mo-bility and localization. The transition to Ethernet issimple and other gateways are possible. The largest partof the implementation is achieved in hardware; howeverimprovements can be made above the MAC layer.

56.4.3 Wireless Sensor/Actuator Networks

Various wireless sensor network (WSN) concepts areunder discussion, especially in the area of industrialautomation. Features such as time synchronized opera-tion, frequency hopping, self-organization (with respectto star, tree, and mesh network topologies), redundantrouting, and secure data transmission are desired. Inter-esting surveys on this topic are available in [56.41–44].Process automation requirements can be generally ful-filled by two mesh network technologies:

• ZigBee (ZigBee Alliance) [56.35]• Wireless HART [56.45, 46].

Both technologies use the standard IEEE 802.15.4(2003) low-rate wireless personal area network(WPAN) [56.33], specifying the physical layer and partsof the data link layer (medium access control).

ZigBeeZigBee distinguishes between three device types:

• Coordinator ZC: root of the network tree, storing thenetwork information and security keys. It is respon-sible for connection the ZigBee network to othernetworks.• Router ZR: transmits data of other devices.• End device ZED: automation device (e.g. sensor),which can communicate with ZR and ZC, but isunable to transmit data of other devices.

An enhanced version allows one to group devicesand to store data for neighboring devices. Addition-ally, to save energy, there are full-function devices andreduced-function devices. The ZigBee application layer(APL) consists of three sublayers: application supportlayer (APS) (containing the connection lists of the con-nected devices), an application framework (AF), andZigbee device objects (ZDO) (definition of devicesroles, handling of connection requests, and establish-ment of communication relations between devices).

For process automation, the ZigBee applicationmodel and the ZigBee profiles are very interesting. Theapplication functions are represented by application ob-jects (AO), and the generic device functions by deviceobjects (DO). Each object of a ZigBee profile can con-tain one or more clusters and attributes, transferred tothe target AO (in the target device) directly or to a co-ordinator, which transfers them to one or more targetobjects.

WirelessHARTRevision 7 of HART protocol includes the speci-fication of WirelessHART [56.46]. The mesh typenetwork allows the use of redundant communicationpaths between the radio-based nodes. The temporal be-havior is determined by the time synchronized meshprotocol (TSMP) [56.47, 48]. TSMP enables a syn-chronous operation of the network nodes (called motes)based on a time slot mechanism. It uses various radiochannels (supported by the MAC layer) for an end-to-end communication between distributed devices. Itworks comparably with a frequency hopping mech-anism missed in the basic standard IEEE 802.15.4.

PartF

56.4

Industrial Communication Protocols 56.5 Wide Area Communications 993

TSMP supports star, tree, as well as mesh topolo-gies. All nodes have the complete routing function(contrary to ZigBee). A self-organization mechanismenables devices to acquire information of neighbor-ing nodes and to establish connections between them.The messages have their own network identifier. Thus,different networks can work together in the same ra-dio area. Each node has its own list of neighbors,

which can be actualized when failures have beenrecognized.

To support security, TSMP uses mechanisms forencryption (128 bit symmetric key), authentification(32 bit MIC for source address), and integrity (32 bitMIC for message content). Additionally, the frequencyhopping mechanism improves the security features. Fordetailed information see [56.46].

56.5 Wide Area Communications

With the application of remote automation mechanisms(remote supervisory, operation, service) using widearea networks, the stock of existing communicationtechnology becomes broader and includes the follow-ing [56.18]:

• All appearances of the Internet (mostly supportingbest effort quality of services)• Public digital wired telecommunication systems: ei-ther line-switched [e.g. integrated services digitalnetwork (ISDN)] or packet-switched [such as asym-metric/symmetrical digital subscriber line (ADSL,SDSL)]• Public digital wireless telecommunication systems(GSM-based, GPRS-based, UMTSbased)• Private wireless telecommunication systems, e.g.trunk radio systems.

The transition between different network technolo-gies can be made easier by using multiprotocol labelswitching (MPLS) and synchronous digital hierarchy(SDH). There are several private protocols (over leasedlines, tunneling mechanisms, etc.) that have been usedin the automation domain using these technologies.Most of the wireless radio networks can be used in nonreal-time applications, some of them in soft real-timeapplications; however industrial environments and in-dustrial, scientific, and medical (ISM) band limit theapplications. Figure 56.9 depicts the necessary remotechannels.

The end-to-end connection behavior via thesetelecommunication systems depends on the recently of-fered quality of service (QoS). It strongly limits theuse of these systems within the automation domains.Therefore, the following application areas have to bedistinguished:

Non-Real-Time Communication in Automation• Non real-time communication (Standard IT: up-load/download, SNMP) with lower priority to real-

time communication: for configuration, diagnostics,automation-specific up/download.• Manufacturing-specific functions, context manage-ment, establishment of application relationships andconnection relationships to configure IO devices,application monitoring to read status data (diagnos-tics, I&M), read/write services (HMI, applicationprogram), open loop control.

The automation domain has the following im-pact on non real-time WAN connections: addressingbetween multiple distributed address spaces, and redun-dant transmission for minimized downtime to ensure itsavailability for a running distributed application.

Real-Time Communication in Automation• Cyclic real-time communications (i. e. PROFINETIO data) for closed loop control and acyclicalarms (i. e. PROFINET IO alarms) as majormanufacturing-specific services• Transfer (and addressing) methods for RT dataacross WAN can be distinguished as follows:

Communication channel CRs

IO deviceIO controller

Configuration datarecord data

Real-timeNon real-time

IOO OIO devdev

AlarmsIO data

Fig. 56.9 Remote communication channels over WAN (input/output (IO); communication relation (CR))

PartF

56.5

994 Part F Industrial Automation

– MAC based: Tunnel (real-time class 1, partiallyreal-time class 2 for longer send intervals, e.g.512 ms), clock across WAN and reserved sendphase for real-time transmission

– IP based: Real-time over UDP (routed); webservices based [56.49, 50].

The automation domain has the following impact onreal-time WAN connections: a constant delay-sensitiveand jitter-sensitive real-time base load (e.g. in LAN: upto 50% bandwidth reservation for real-time transmis-sion).

To use a wide area network for geographicallydistributed automation functions, the following basicdesign decisions were made following the definitions inSect. 56.2:

• A virtual automation network (VAN) is an in-frastructure for standard LAN-based distributedindustrial automation concepts (e.g. PROFINET orother) in an extended environment. The productiveautomation functions (applications) are describedby their object models used in existing industrialcommunications. The application service elements(ASEs), as they are specified in the IEC 61158 stan-dard, can additionally be used.• The establishment of the end-to-end connections be-tween distributed objects within a heterogeneousnetwork is based on web services. Once this con-nection has been established, the runtime channelbetween these objects is equivalent to the runtimechannel within the local area by using PROFINET(or other) runtime mechanisms.• The VAN addressing scheme is based on namesto avoid the use of IP and MAC addresses duringestablishment of the end-to-end path between logi-cally connected applications within a VAN domain.Therefore, the IP and MAC addresses remain trans-parent to the connected application objects.• Since there is no new Fieldbus or real-time Eth-ernet protocol, no new specified application layeris necessary. Thus, the well-tried models of indus-trial communications (as they are specified in theIEC 61158 standard) can be used. Only the ad-ditional requirements caused by the influence ofwide area networks have to be considered and theylead to additional functionality following the above-mentioned design guidelines.

Most of the WAN systems that offer quality-of-service (QoS) support cannot provide real guarantees,and this strongly limits the use of these systems within

the automation domain. To guarantee a defined QoSfor data transmission between two application accesspoints via a wide area network, written agreementsbetween customer and service provider [service levelagreements (SLA)] must be contracted. In cases wherethe provider cannot deliver the promised QoS, an alter-native line must be established to hold the connectionfor the distributed automation function (this operation isfully transparent to the application function). This lineshould be available from another provider, independentfrom the currently used provider. The automation de-vices (so called VAN access points (VAN-APs)] shouldsupport functions to switch (either manually or automat-ically) to an alternative line [56.51].

There are different mechanisms to realize a connec-tion between remote entities:

• The VAN switching connection: the logical connec-tion between two VAN-APs over a WAN or a publicnetwork. One VAN switching connection owns oneor more communication paths. VAN switching lineis defined as one physical communication path be-tween two VAN-APs over a WAN or a publicnetwork. The endpoints of a switching connectionare VAN-APs.• The VAN switching line: the physical communica-tion path between two VAN-APs over a WAN ora public network. A VAN switching line has itsprovider and own QoS parameter. If a provider of-fers connections with different warranted QoS eachof these shall be a new VAN switching line.• VAN switching endpoint access: the physical com-munication path between one VAN-AP and a WANor a public network. This is a newly introduced classfor using the switching application service elementsof virtual automation networks for communicationvia WAN or public networks.

These mechanisms are very important for the conceptof VANs using heterogeneous networks for automa-tion. Depending on the priority and importance of thedata transmitted between distributed communicationspartners, the kind of transportation service and com-munication technology is selected based on economicalaspects. The VAN provider switching considers the fol-lowing alternatives:

• Use case 1: For packet-oriented data transmissionvia public networks a connection from a corre-sponding VAN-AP to the public network has to beestablished. The crossover from/to the public net-work is represented by the VAN switching endpoint

PartF

56.5

Industrial Communication Protocols 56.7 Emerging Trends 995

access. The requirements made for this line have tobe fulfilled by the service level agreements from thechosen provider. Within the public network it is notpossible to influence the quality of service. The datapackage leaves the public network when the VANswitching endpoint access from the faced communi-cation partner is achieved. The connection from thepublic network to the faced VAN-AP is also pro-vided by the same or an alternative provider andguarantees defined requirements. The data exchangebetween two communication partners is indepen-dent of each other.

• Use case 2: For a connection-oriented data trans-mission (or data packages with high-level priority)the use of manageable data transport technology isneeded. The VAN switching line represents a man-ageable connection. A direct known connectionbetween two VAN-APs has to be established anda VAN switching endpoint access is not needed.The chosen provider guarantees the defined require-ments for the complete line. When the current lineloses the promised requirements it is possible to de-fine the VAN-APs to build up an alternative line andhold on/disconnect the current line automatically.

56.6 Conclusions

As discussed in the above sections, the area of indus-trial communication protocols has been experiencinga tremendous evolution over the last ten years, beingstrongly influenced by advances in the area of informa-tion technology and hardware/software developments.Existing industrial communication protocols have im-pacted very positively both in the operation of industrialplants, due to enhanced diagnostic capabilities, whichhas improved maintenance operations, as well as in thedevelopment of complex automation systems.

The chapter has reviewed the main concepts ofindustrial communication networks and presented themost prominent wired and wireless protocols that are

already incorporated in a large number of industrial de-vices (from thousands to millions).

Within this scope of a multitude of existing proto-cols and also motivated by the growth of the Internetand increasing possibilities of the World Wide Webnetwork, and the increased demand for geographicallydistributed automation functions virtual automation net-works (VAN), a very interesting approach would appearto be to allow integration via heterogeneous networks.The section presented the concepts of VAN domainsand interfaces and the challenges on ensuring timelycommunication behavior, safety, and security acrossmultiple VAN domains.

56.7 Emerging Trends

The number of commercially available industrial com-munication protocols has continued to increase, despitesome trials to converge to a single and unified pro-tocol, in particular during the definition of the IEC61178 standard; the automation community has startedto accept that no single protocol will be able to meetall different communication requirements from differ-ent application areas. This trend will be continued bythe emerging wireless sensor networks as well as theintegration of wireless communication technologies inall mentioned automation-related communication con-cepts. Therefore, increasing attention has been givento concepts and techniques to allow integration amongheterogeneous networks, and within this context vir-tual automation networks are playing an increasingrole.

With the proliferation of networked devices withincreasing computing capabilities, the trend of de-centralization in industrial automation systems willincrease in the future (Figs. 56.10 and 56.11). This sit-uation will lead to an increased interest in autonomicsystems with self-X capabilities, where X stands foralternatives as configuration, organizing, optimizing,healing, etc. The idea is to develop automation sys-tems and devices that are able to manage themselvesgiven high level objectives. Those systems should havesufficient degrees of freedom to allow a self-organizedbehavior, which will adapt to dynamically changing re-quirements. The ability to deal with widely varying timeand resources demands while still delivering depend-able and adaptable services with guaranteed temporalqualities is a key aspect for future automation systems.

PartF

56.7

996 Part F Industrial Automation

SCADA

Just onepower cable....

UWB

Location

sensing

Ethernet

HSDPAUMTS

Sensors

Actuators

LBS

Controlparameterization

set-up

Fig. 56.10 The wireless factory (from [56.52])

• Ubisense UWB-realtime positioning system

• RFID grid for mobile workshop navigation

• Cricket ultrasonic indoor location system

Fig. 56.11 Indoor positioning systems in the SmartFactory (from [56.52])Part

F56.7

Industrial Communication Protocols 56.8 Further Reading 997

56.8 Further Reading

56.8.1 Books

• J.W.S. Liu: Real-Time Systems (Prentice Hall, Up-per Saddle River 2000)• P.S. Marshall: Industrial Ethernet (ISA, 2004)• P. Pedreiras, L. Almeida: Approaches to enforcereal-time behavior in Ethernet. In: The Indus-trial Communication Technology Handbook, ed. byR. Zurawski (CRC, Boca Raton 2005)• B. Schneider: Secrets and Lies – Digital Security ina Networked World (Wiley, New York 2000)• L.R. Franco, C.E. Pereira: Real-time characteristicsof the foundation Fieldbus protocol. In: Field-bus Technology: Industrial Network Standards forReal-Time Distributed Control, ed. by N.P. Ma-halik (Springer, Berlin Heidelberg 2003), pp. 57–94

56.8.2 Various Communication Standards

• IEC: IEC 61508: Functional safety of elec-trical/electronic/programmable electronic safety-related systems (2000)• IEC: IEC 61158 Ser., Edition 3: Digital data com-munication for measurement and control – Fieldbusfor use in industrial control systems (2003)• IEC: IEC 61784-1: Digital data communications formeasurement and control – Part 1: Profile sets forcontinuous and discrete manufacturing relative toFieldbus use in industrial control systems (2003)• PROFIBUS Guideline: PROFInet Architecture De-scription and Specification, Version V 2.0 (PNO,Karlsruhe 2003)

56.8.3 Various web Sites of FieldbusOrganizations and Wireless Alliances

• IEEE 802: http://www.ieee802.org (last accessedApril 6, 2009)

• HART Communication Foundation:http://hartcomm.org (last accessed April 6, 2009)• ODVA: http://www.odva.org (last accessed April 6,2009)• PROFIBUS Nutzer Organisation/PROFIBUS In-ternational: http://www.profibus.com (last accessedApril 6, 2009)• Interbus Club: http://www.interbusclub.com (lastaccessed April 6, 2009)• Fieldbus Foundation: http://www.fieldbus.org (lastaccessed April 6, 2009)• MODBUS: http://www.modbus.org/ (last accessedApril 6, 2009)• Actor-Sensor-Interface ASi:http://www.as-interface.net (last accessed April 6,2009)• Ethernet POWERLINK Standardization Group(EPSG): http://www.ethernet-powerlink.org (lastaccessed April 6, 2009)• EtherCAT Technology Group:http://www.ethercat.org (last accessed April 6,2009)• Interessengemeinschaft SERCOS interface e.V.:http://www.ig.sercos.de (last accessed April 6,2009)• IEEE 802.11TM Wireless Local Area Networks:http://ieee802.org/11/ (last accessed April 6, 2009)• ZigBee Alliance: http://www.zigbee.org (last ac-cessed April 6, 2009)• Bluetooth Special Interest Group:http://www.bluetooth.org (last accessed April 6,2009)• WISA: Wireless Interface for Sensors and Actua-tors: http://library.abb.com/global/scot/scot209.nsf/veritydisplay/4e478bd7490a3f8bc12571f100427dcb/$File/2CDC171017K0201.PDF (last acces-sed April 6, 2009)• Virtual Automation Networks (VAN):http://www.van-eu.eu/ (last accessed April 6, 2009)

PartF

56.8

998 Part F Industrial Automation

References

56.1 P. Neumann: Communication in industrial au-tomation – what is going on?, INCOM 2004, 11thIFAC Symp. Inf. Control Probl. Manuf., Salvador daBahia (2004)

56.2 IEC 61508: Functional safety of electrical/electronic/programmable electronnic safety-related systems(2000)

56.3 P. Neumann, A. Pöschmann, E. Flaschka: Virtualautomation networks, heterogeneous networks forindustrial automation, atp Int. Autom. Technol.Pract. 2, 36–46 (2007)

56.4 Virtual Automation Networks: European IntegratedProject FP6/2004/IST/NMP/2 016696 VAN. DeliverableD02.2-1: Topology Architecture for the VAN VirtualAutomation Domain (2006)

56.5 HART: http://www.hartcomm2.org/ (last accessedApril 6, 2009)

56.6 R. Becker, B. Müller, A. Schiff, T. Schinke,H. Walker: A Compilation of Technology, Function-ality and Application (AS International Association,Gelnhausen 2002)

56.7 CAN: IEC 11898 Controller Area Networks: http://de.wikipedia.org/wiki/Controller_Area_Network (lastaccessed April 6, 2009), see also http://www.can-cia.org/canopen

56.8 IO-Link Communication Specification, V 1.0;PROFIBUS International 2.802 (2008)

56.9 IO-Link Integration, Part 1, V. 1.00; PROFIBUS Inter-national 2.812 (2008)

56.10 PROFIBUS: Technical description,http://www.profibus.com/pb/ (last accessed April6, 2009)

56.11 IEC 61158 Ser., Edition 3: Digital data communica-tion for measurement and control – Fieldbus foruse in industrial control systems (2003)

56.12 IEC 61784-1: Digital data communications for mea-surement and control – Part 1: Profile sets forcontinuous and discrete manufacturing relative tofieldbus use in industrial control systems (2003)

56.13 ANSI/TIA/EIA-485-A: Electrical characteristics ofgenerators and receivers for use in balanced digitalmultipoint systems (1998)

56.14 ODVA: http://www.odva.org/portals/ (last accessedApril 6, 2009)

56.15 MODBUS TCP/IP: IEC 65C/341/NP: Real-Time Ethernet:MODBUS-RTPS (2004)

56.16 Ethernet IP: Ethernet/IP specification, Release 1.0.,(ControlNet International and Open DeviceNet Ven-dor Association, 2001)

56.17 High Speed Ethernet: HSE Specification documentsFF-801, 803, 586, 588, 589, 593, 941 (FieldbusFoundation, Austin 2001)

56.18 P. Neumann: Communication in industrial au-tomation. What is going on?, Control Eng. Pract.15, 1332–1347 (2007)

56.19 PROFIBUS Nutzerorganisation: PROFInet Architec-ture Description and Specification, Version V 2.0.,PROFIBUS Guideline (2003)

56.20 P-Net on IP: IEC 65C/360/NP: Real-Time Ethernet:P-NET on IP (2007)

56.21 PROFINET IO: IEC 65C/359/NP: Real-Time Ethernet:PROFINET IO, Application Layer Service Defini-tion and Application Layer Protocol Specification(2004)

56.22 P. Neumann, A. Pöschmann: Ethernet-based real-time communication with PROFINET IO, WSEASTrans. Commun. 4(5), 235–245 (2005)

56.23 Time-critical Control Network: IEC 65C/353/NP:Real-Time Ethernet: Tcnet (2007)

56.24 Vnet/IP: IEC 65C/352/NP: Real-Time Ethernet:Vnet/IP (2007)

56.25 POWERLINK: IEC 65C/356/NP: Real-Time Ethernet:POWERLINK (2007)

56.26 ETHERCAT: IEC 65C/355/NP: Real-Time Ethernet:ETHERCAT (2007)

56.27 W. Manges, P. Fuhr (Eds.): PROFINET IO/IsochronousTechnology, IFAC Summer School Control, Comput-ing, Communications, Prague (2005)

56.28 J. Jasperneite, K. Shehab, K. Weber: Enhancementsto the time synchronization standard IEEE-1588 fora system of cascaded bridges, 5th IEEE Int. Work-shop Fact. Commun. Syst., WFCS2004, Vienna (2004)pp. 239–244

56.29 EtherNet/IP with time synchronization: IEC 65C/361/NP: Real-Time Ethernet: EtherNet/IP with time syn-chronization (2007)

56.30 IEC 61588: Precision clock synchronization protocolfor networked measurement and control systems(2002)

56.31 SERCOS III: IEC 65C/358/NP: Real-Time Ethernet: SER-COS III (2007)

56.32 Wireless LAN: IEEE 802.11: IEEE 802.11 Wireless LocalArea Networks Working Group for WLAN Stan-dards, http://ieee802.org/11/ (last accessed April 6,2009)

56.33 Personal Area Networks: IEEE 802.15: IEEE 802.15Working Group for Wireless Personal Area Net-works, Task Group 1 (TG1), http://www.ieee802.org/15/pub/TG1.html (last accessed April 6, 2009), and:Task Group 4 (TG4), http://www.ieee802.org/15/pub/TG4.html (last accessed April 6, 2009)

56.34 Bluetooth: The Official Bluetooth Membership Site,https://www.bluetooth.org (last accessed April 6,2009)

56.35 ZigBee: http://www.zigbee.org/ (last accessed April6, 2009)

56.36 WISA: http://library.abb.com/GLOBAL/SCOT/SCOT209.nsf/VerityDisplay/4E478BD7490A3F8BC12571F100427DCB/$File/2CDC171017K0201.PDF (last ac-cessed April 6, 2009)

PartF

56

Industrial Communication Protocols References 999

56.37 ABI Research Forecast and Information on Emerg-ing Wireless Technologies:http://www.abiresearch.com (last accessed April 6,2009)

56.38 W. Stallings: IEEE 8O2.11. Wireless LANs from a to n,IT Professional 6(5), 32–37 (2004)

56.39 IEEE 802.11 Tutorial:www.eecs.berkeley.edu/˜ergen/docs/ieee.pdf(last accessed April 6, 2009), see also http://ayman.elsayed.free.fr/msc-student/wlan.tutorial.pdf

56.40 A. Willig, K. Matheus, A. Wolisz: Wireless technologyin industrial networks, Proc. IEEE 93(6), 1130–1151(2005)

56.41 P. Neumann: Wireless sensor networks in processautomation, survey and standardisation, atp 3(49),61–67 (2007), (in German)

56.42 I.F. Akyildiz: Key wireless networking technologiesin the next decade, IFAC Conf. Fieldbus Technol. FeT2005, Puebla (2005)

56.43 K. Koumpis, L. Hanna, M. Andersson, M. Johansson:Wireless industrial control and monitoring beyondcable replacement, PROFIBUS Int. Conf. CoombeAbbey, Warwickshire (2005), Paper C1

56.44 Industrial wireless technology for the 21st cen-tury, Industrial Wireless Workshop, San Francisco(2002)

56.45 J.-L. Griessmann: HART protocol rev. 7 includingWirelessHART, atp Int.-Autom. Technol. Pract. 2,21–22 (2007)

56.46 HART 7: HART Protocol Specification, Revision 7(HART Communication Foundation, 2007), see alsohttp://www.hartcomm.org/ (last accessed April 6,2009)

56.47 Dust Networks: TSMP Seminar. Online-Präsentation(2006)

56.48 Dust Networks: Technical Overview of Time Syn-chronized Mesh Protocol (TSMP), White Paper (DustNetworks, 2006)

56.49 IBM: Standards and Web services, http://www-128.ibm.com/developerworks/webservices/standards/(last accessed April 6, 2009)

56.50 L. Wilkes: The web services protocol stack, Re-port from CBDI Web Services Roadmap (2005),http://roadmap.cbdiforum.com/reports/protocols/(last accessed April 6, 2009)

56.51 Virtual Automation Networks: European IntegratedProject FP6/2004/IST/NMP/2 016696 VAN. DeliverableD07.2-1: Integration Concept, Architecture Specifi-cation (2007)

56.52 D. Zuehlke: SmartFactory from vision to realityin factory technologies, IFAC Congress 2008, Seoul(2008)

PartF

56