Fieldbus Technology

The smart choice of Fluid Control Systems

Contents

IntroductionIntelligent technology in the field Page 6

1. Technology 1.1. Function of field bus technology Page 8

1.2. Automation with field bus technology Page 10

1.3. Advantages of using field bus technology Page 13

1.4. Industry requirements on a field bus Page 14

2. PROFIBUS2.1. Mode of operation Page 16

2.2. PROFIBUS as a ”modular system“ Page 17

2.3. Transmission systems Page 18

2.4. Communication system: The PROFIBUS DP protocol Page 21

2.5. Application profiles Page 22

2.6. Integrationsystem Page 23

3. FOUNDATION Fieldbus3.1. Distributed intelligence Page 26

3.2. The network is the control Page 27

3.3. Link Active Scheduler Page 28

3.4. The application is produced by function blocks Page 29

3.5. Description and integration of field bus devices Page 29

4

4. Ethernet4.1. Mode of operation Page 30

Topology Page 30

4.2. Real-time capability Page 31

4.3. Automation standards Page 32

4.3.1. PROFInet Page 32

4.3.2. Powerlink Page 34

4.3.3. Ethernet/IP Page 36

4.3.4. IDA Page 38

4.3.5. High-Speed-Ethernet Page 40

5. CAN (CANopen/DeviceNet)5.1. Mode of operation Page 42

5.2. Topology Page 42

5.3. Bus access procedures Page 43

5.4. International standardization: CANopen and DeviceNet Page 44

Features of CAN Page 45

6. INTERBUS6.1. INTERBUS topology Page 47

6.2. INTERBUS LOOP Page 47

6.3. Advantages of INTERBUS Page 47

5

7. AS-Interface7.1. Mode of operation Page 48

7.2. Topology Page 48

7.3. Transmission reliability and interference immunity Page 48

7.4. Safety at Work Page 49

7.5. Basic data of AS-Interface Page 49

8. HART8.1. Cabling Page 51

8.2. HART commands Page 51

9. Communications-enabled field units from BürkertControl units for pneumatically operated process valves Page 52

Valve couplers Page 52

Valve islands Page 52

Sensors Page 53

Mass flow controllers/meters (MFC/MFM) Page 53

Other field bus devices Page 53

10. List of keywords Page 54

The status quo:Application-specificstandardization of sy-stems

As a key technology in the automationsector, field bus technology now offersa range of standardized bus systemsthat have been specialized and optimiz-ed for specific industries or specificapplications.Opening up this intelligent technologywith optimum efficiency for the custom-er is a welcome and sought-after challenge for our teams of consultantswho, owing to their pioneering expe-rience, possess the crucial knowledgefor developing future-oriented solu-tions. And what would highly qualifiedengineers find more motivating than an unsolved problem? The fact that Bürkert has the “tickets” for future-oriented field bus technology world-wide makes the choice simple for ourcustomers, but “difficult” for our ex-perts who wish to be challenged bynew tasks.

6

The eighties was the decade in which automation technology made a fundamental leap in quality. The parallel wiring that was conventionaluntil then was contrary to the need for complex communication with in-creasingly more digitized field unitsthat ensured greater intelligence ofthe functional components in the field.Gradually, solutions with conventionalwiring technology were displaced by advanced field bus technology.

On the search for compatibility and universality

As is the case with every genuine innovation, field bus technology alsoinitially further developed in compe-tition with differentiated solutionswhich were linked to “company-own”components. What was currently possible did not always coincide withthe potential and dynamics of whatwas, in principle, an “open” technology. Catching the right bus became theessential question, and one which Bürkert responded to with a consist-ently customer-oriented approach towards practically-oriented stand-ardization. The aim was just as simpleas it is was elementary: units from different manufacturers should be ableto be operated by the same bus sy-stem.

In te l l igent technology in the f ie ld

EtherNet

7

Catching the right bus

The “evolution” of network technologyhas essentially developed from theprinciple of centralization through todistributed intelligence. Of course,this also necessitates componentsthat comply with all aspects of thenew "command structure”. Maximumavailability and minimum possibledowntimes are but two key aspects ofmore efficient, i.e. advanced, opera-tion of a system or installation whichis based on future-proof field bustechnology. It is certainly worth consid-ering opting for a technology leaderwho has been involved right from thevery start and who can therefore pro-vide the appropriate solution to an individual problem as an integratedsystem. With Bürkert, you are ridingthe bus to the future.

Networking: informa-tion on the future ofnetworking

Various user associations track theongoing development of individualbus systems. Visiting the followingwebsites will fill you in on the latest:

■ AS-International Association www.as-interface.net

■ CANopen www.can-cia.de

■ DeviceNet www.odva.org

■ Ethernet www.iaona-eu.com www.ida-group.org www.odva.orgwww.profibus.com

■ FOUNDATION Fieldbus www.fieldbus.org

■ HART Communication Foundationwww.hartcomm.org

■ INTERBUS Club www.interbusclub.com

■ PROFIBUS International (PI)www.profibus.com

Central

Open-loop control

Distributed

Distributed network

Data

Data

Program

Program

Communication relationships/Data exchange

Application 1,e.g. PLC

Application 2,e.g. CNC

Application 3, e.g. visualization

Distribution of variables in the network

Open-loop control

c c

Factory or coordinating level

Plant installations

Automation level

Field level

8

1.1.Function of field bustechnology

1.1.1 CommunicationField buses enable the digital net-working of open-loop control systems,sensors and actuators. Data is ex-changed both horizontally between thedevices of a level and vertically to thesystems in the next hierarchy level.

In order to achieve a practically-oriented classification, we assign thecommunication structures in automa-tion engineering to various application levels (Figure 1).

The coordinating level monitors higher-level plant control while the automationlevel controls the actual process. Thefocus is on the reliable transmission ofeven very long messages (file transfer).At the field level, data transmission ofthe measured values and manipulatedvariables is cyclic in many cases andnecessitates as high an efficiency aspossible so as not to impair real-timecharacteristics of the open-loop con-trol application. In this connection, weusually speak of data-oriented com-munication. Moreover, field buses alsosupport access to field units of theupper levels, e.g. engineering stationsfrom the automation or coordinatinglevel. Process data and status infor-mation can be read out, parameterscan be polled and set and, in somecases, software can even be down-loaded and program routines startedfor configuration, operation, monitor-ing and diagnosis, at the instigation of the user. This form of acyclic dataexchange is referred to as message-oriented communication.

Figure 1: Application levels in automation engineering

1 . Technology

9

1.1.2. Network topologiesAll field bus systems are based on the same idea of allowing addressabledevices to use a common transmissionmedium. The network topology de-scribes the spatial extent of a fieldbus network, but also the logical arrangement of the devices duringcommunication.

■ LinearThe bus or linear structure is clearlyarranged and features little com-plexity. This is where all users communicate via a common line.The devices are linked either with or with-out very short stubs. Occasionally, this leads to untidycabling in practice.

■ TreeThe tree structure is similar to thelinear structure, the only differencebeing that several bus branchesmay converge at the nodes. Thetree structure enables large areasto be networked more easily andmore flexibly.

■ RingIf a physical ring is constructedwith several two-point connections,it is termed a ring structure. A mes-sage to be transferred is passedon from one user to the next. Sincethe signal can be amplified eachtime it is passed on, it is possibleto span very large distances.

A

D

F B

E C

A B

D E

C

F

A C

B D

E

■ Star A central station is linked to allusers with two-point connectionsin a star structure. This central sta-tion may either be responsible fornetwork control as the Master, oras a “star coupler”, may simply establish the connection between the current sender and receiver.

Complex network structures frequentlyconsist of several independent sub-networks. Each of these sub-networkscan work with differing topology and a different communication protocol.

A

D

F

G

B

E C

1.2. Automation with fieldbus technology

1.2.1. Hierarchy levels infield bus networksDue to the various technical optionsand characteristics of the individualbus systems, system discontinuitymay occur in the installations if theuser uses different bus systems or variants of a bus system, for instance,in order to access the explosion-haz-ard area with the aid of PROFIBUSPA via PROFIBUS DP. Simple net-working of the components used isjust as important as linking them to lower-level and higher-level networkstructures. This may be achievedusing gateways (protocol converters),which allow transition between the various bus systems.

Utilizing a gateway, the AS-i system,for example, which is particularly suit-able for data exchange within the I/Olevel (input/output level for generallysimple sensor and actuator systems),can thus be integrated in a higher-level field bus, such as INTERBUS orPROFIBUS, which possess broadertechnical capabilities in the area ofthe field and process level.

In turn, field level buses offer interwork-ing with Ethernet for communicationwith higher-level networks. The pro-cess and parameter data is forwardedthis way and enables vertical integra-tion of the application.

10

7 Application layer

6 Presentation layer

5 Session layer

4 Transport layer

3 Network layer

2 Data link layer

1 Physical layer

Sender Receiver

7 Application layer

6 Presentation layer

5 Session layer

4 Transport layer

3 Network layer

2 Data link layer

1 Physical layer

Application-oriented layers

Transport-oriented layers

Physical transmission medium

Figure 2: ISO/OSI model

Generally, only layers one and two are fully defined when specifying field bus networks, while the applicationprocess itself or the subordinate layer seven handles all other services.

■ Layer one defines the way inwhich data transmission is perfor-med physically, i.e. electrically andmechanically. This includes, forexample, the method of coding(e.g.: NRZ) and the transmissionstandard used (e.g.: RS-485).

■ Layer two has the task of provid-ing integral, i.e. error-free, information. It must detect any errorswhich have occurred in layer oneand remedy these errors via suitableerror routines.

■ Layer seven forms the interface to the application program andcontains all functions with whichthe user, generally a computer program, can access the commu-nication functions.

1.1.3. StandardizationRules must be defined for all commu-nication partners so that communica-tion between various users and acrossthe network hierarchy levels can occureffectively and without misunderstand-ings. This is achieved with the ISO/OSI model (Figure 2), which describesall elements required for communicat-ion, such as the cable type or physicalmode of transmission of the messages.The model features seven layers thatbuild upon each other, each of whichdescribes a specific task.

The ISO/OSI model has also becomeestablished as a virtual standard re-presentation when implementing com-munication services outside of fieldbus technology, since it fundamentallydescribes the communication sequence.If specific services (layers) are no lon-ger required within a communicationsystem, these layers remain empty.

11

Even today, Ethernet already plays acrucial role in higher-level structures.Practical vertical integration allowsuniversality of presentation and avail-ability of process data and systemstatuses. If the machines and systemsinterwork with Ethernet (via subordi-nate bus structures), the resultantcentral system operation and tele-maintenance provide the user with a great savings potential.

1.2.2. Dynamics of fieldbus communicationIf Ethernet is to be used in automationengineering instead of a classic fieldbus system, (“hard”) real-time capabil-ity is particularly important.

Basically, the term “real time” is aquestion of definition. Thus, real timein the case of synchronization of dri-ves or actuators may amount to mi-croseconds, while times in terms ofseconds are adequate in process-engineering applications.

If we compare the various field bussystems and Ethernet with regard toefficiency of data transmission, Ether-net achieves a poorer value. This re-sults from the CSMA/CD procedureused (see also Section 4.1.), whichmust operate with a long minimum telegram length due to unconditionaland secure collision detection. However, this disadvantage is com-pensated for by the high transmissionspeeds of up to 100 Mbit/s.

Such high transmission speeds canbe implemented only by a point-to-point connection between the units,which, besides Ethernet, is only offer-ed by the INTERBUS system.On systems with a variable transmis-sion speed, such as PROFIBUS orCAN, the maximum possible networkextent is reduced with increasing transmission speed. The higher thetransmission speed, the shorter theline length. This may lead to a situa-tion in which the communication linkto be laid is only a few meters long,which is not necessarily disadvan-tageous within closed systems or sy-stem sections.

Figure 3: Hierarchy levels in automation engineering

System-oriented asset management is aimed not only at maintaining anexisting system, but is already deploy-ed in the engineering of componentsin process control engineering. It in-clud-es programming and configuringthe field units and opens up access to system documentation and to theoperating environment of the installa-tion.

Measured on the basis of the lifecycleof an installation, maintenance and, in particular, status detection of fieldunits and other system componentsare very important. Measured valueswhich characterize the status ofequipment and machines and whichare processed by the asset manage-ment system (AMS) on the basis ofcharacteristics or models to formtrend information or which combinethese values centrally from other in-formation systems are used for thispurpose.

12

1.2.3. Operational optimi-zation by asset manage-mentThe aim of asset management in automation is to effectively manageand optimize the use of equipmentand systems. This includes, for in-stance, the ability to plan the requiredmaintenance, minimization of faultsoccurring, enhancement of processdiagnostics and process monitoringas well as both identification and utilization of function reserves.

This requires complex information that must be obtained from the overallautomation system. Asset manage-ment can function only by the inter-play of intelligent field units, a highlydeveloped communication structureand corresponding operating soft-ware. Thus, for example, diagnosticinformation from the field level is sentvia the field bus to corresponding asset management stations where it is evaluated.

Figure 4: Asset management operating program

Status of system components with display of alarms

Maintenance actions

Automatic e-mail

Error trend

Database with Help function

ameliorate this situation, proprietarydescriptions (languages) based onthe Standard Device DescriptionLanguages (DDLs) have been develop-ed. However, each of these languagesis tailored to the specific communica-tion systems for which it was originallydeveloped. Virtually every configura-tion tool and every field bus standardhas implemented its own device des-cription language or at least uses a dialect of the HART Device Description,which was developed at a very earlypoint. The operating methods forPROFIBUS (GSD, EDD, DTM), HARTdevices (DD), DeviceNet (EDS) andFOUNDATION Fieldbus devices (DD,DTM) are examples that emerged from this.

Thanks to the creation of an open andstandardized communication platform,at least referring to the relevant sy-stem, field units are able to be easilyintegrated in the given control and instrumentation system structure andoperated centrally via a common engi-neering tool.

1.3. Advantages of usingfield bus technology

Comprehensive costing of an automa-tion solution will cover the investmentcosts required for procuring the MCRequipment. Just as importantly, it isalso necessary to allow for costs in-curred during commissioning andsubsequent expansion and conversionduring system operation. The term“Total Cost of Ownership” has comeinto being for this cost analysis.

■ Wiring systemUsing a field bus drastically reduc-es the cabling expenses, effort and complexity. While thick cable harnesses were run between MCR area and the field using convention-al technology, field bus technology enables integrating the same I/Os by using one pair of conductors. This advantage is escalated in the savings on terminal blocks, control cubicles, lightning protection facili-ties and explosion barriers.

13

As the decision-making basis formaintenance measures, AMS mustalso offer access to documents suchas shift logs, system documentationand CAE systems, in addition to cur-rent status information.

With all asset management solutions,it is necessary to bear in mind the basic requirement that all technicaloperational support activities have tobe performed from one workstation.

1.2.4. Central device managementIf a field bus network is constructedon the basis of devices from one sin-gle manufacturer and if the manufac-turer’s devices can all be operated in the same way, one manufacturer-specific software package suffices asthe user interface. However, an aver-age installation can certainly cover over 100 different field unit types from ten or more different manufacturers,which frequently also may involve tenor more different operating programsfor configuring and programming thefield units. In order to at least partially

4-20 mA devices (HART)

Field bus-enabled devices

Gateway

Central engineering

PLC

Remote I/O

Field bus

Figure 5: Device operation

For the user, this brings a tremend-ous savings potential in terms ofspace requirement and costs forthe entire MCR wiring.

One other tremendous advantage is as follows: The reduction in wir-ing effort and expense leads to the same reduction in documentation expenditures related to all electricalwiring diagrams and ladder dia-grams.

■ FlexibilityA new field unit can be added to a field bus at any point without having to separately lay a completecable raceway. Subsequent modi-fications and extensions thus poseno problem. This applies in parti-cular to wiring with the two-wiresystem in which data and powerare transferred in one cable.

■ CommissioningSignificant advantages can be anti-cipated in relation to the durationof the commissioning phase. Mod-ern technologies mean faster inte-gration of the field components(loop check and calibration) in theprocess control system. Wiring errors are prevented thanks to thesimple cabling. If difficulties withinthe network structure occur never-theless, these are rapidly diagnos-ed using bus testers and bus monitors.

■ MaintenanceWarning and error signals of theprocess devices constantly informthe system operator of the currentoperating state of the system. Thisallows the system operator to pre-cisely assess the situation and takesuitable measures based on it.

For example, if a measuring circuitmalfunction occurs on a controlvalve, maintenance personnel areinformed of the error or fault detect-ed. Owing to the access to thefield unit via operating programs,the maintenance technician receiv-es detailed information on the fault or error which has occurredand can remedy the situation in targeted manner and within a veryshort time.

■ System availabilityOne other substantial cost advan-tage results from the reduction indowntimes as a result of unequi-vocal and detailed diagnosis from the field units and an associatedenhanced machine and systemavailability. Intelligent field units issue precise fault or error descrip-tions to the system operator oreven signal failures before they occur (predictive maintenance).

■ UniversalityAll process data, device data orbusiness management data is avail-able via a universal communicationstructure from all locations, andeven outside of the system via theInternet. This allows central and di-stributed operation and engineer-ing. Comprehensive and centraldata management forms the basisfor operational optimization in everysystem.

1.4. Industry requirementsof a field bus

Various factors are crucial to selectingthe field bus system to be used. Essentially however, the field bus requirements necessitated by the application play a crucial role. Sinceevery system is able to meet specificrequirements particularly well due toits technical characteristics, variousfield buses have a high share of themarket in individual industries.

Production industryProduction based on lot sizes andexecution of repetitive, frequently mutually independent work steps arecharacteristic of the production indu-stry. The level of decentralization wit-hin a production plant is low.

The requirements applicable to com-munication between programmablecontroller (PLC) and field units arevery stringent. In many sectors, suchas robotics, measuring technologyand test and inspection technology,stringent real-time requirements arisewith cycle times less than 20 milli-se-conds. In many cases, equidistantdata transmission is required in drive engineering, e.g. for axis interpolation.

The requirement regarding safetyagainst system failure is only moderate.In many cases, halting production inthe event of device failure costs lessthan designing the entire system fullyredundantly. More stringent require-ments related to fail-safe design existin areas in which persons may be plac-ed at risk, e.g. burner controls, presscontrols and lathes, etc.

14

15

Process industryProduction is generally batch-orientedin the food industry, chemical industryand pharmaceuticals industry as wellas within the process industry andprocess engineering.

Typically, the process industry utilizesvery complex installations that aregreatly decentralized and implement-ed over a very large area in the formof distributed systems. The volume ofproject data in such installations maycomprise several hundred thousanddata points. This means that the requirements for process control sy-stems are very stringent as regardshandling the data volume. However,the time aspect is less critical and is within the range of seconds in manycases.

One fundamentally important criterionin the process industry is high availa-

bility. The systems are not switchedoff due to the complex and long,drawn-out starting procedures forcontinuous processes, which oftenlast several hours. Expensive redun-dancy concepts with hot standby pre-vent fault or error-related interruptionin the process. The requirements inthe areas of maintenance and com-missioning are correspondingly strin-gent. It must be possible to convert or extend the system during ongoingoperation.

Additional safety requirements applyto explosion-hazard environments,such as in the petrochemical and gasindustries. The entire MCR system inthe field must ensure that the legallyrequired safety regulations, such asATEX Directives, are complied with.Depending on the level of danger orhazard, there is a classification intozones from 0 to 2 which, in turn,

AS-Interface

DeviceNet

CANopen

Interbus

Ethernet

Production industry Process industry

HART (no fieldbus)

FOUNDATION Fieldbus

PROFIBUS PA focus

Zone 1Zone 2

DP focus

allow only specific automation con-cepts, including the communicationmethod to be used.

In the illustration below, widespreadfield bus systems are shown on thebasis of their main applications. Thetypes on the left focus on use in theproduction industry. A special role is assigned to Ethernet, which con-nects industrial networking to officecommunication. The buses for pro-cess automation, which also cover the requirements of the explosion-protected area, are shown on theright. The cross-industry character-istics can also be seen with the PROFIBUS and AS-Interface.

Figure 6: Major industrial focuses of field bus types

PROFIBUS (PROcess FIeld BUS) is a universal, open, digital communica-tion system. It opens up diverse ap-plications from production automationthrough to process automation. PROFIBUS is suitable for fast, time-critical and complex communicationtasks.

2.1. Mode of operation

PROFIBUS uses cyclic data exchangefor communication. Each field unit(slave) exchanges its measured valuesand set-point values with the pro-grammable controller, the Class-1-Master (PLC, controller), in a stipu-lated cycle time (deterministic). Thismaster-slave communication on whichthe field units are served centrally andconsecutively is referred to as polling.

Besides the programmable controller,a visualization system (Class-2 Ma-ster) is also necessary for system mo-nitoring and operation. The Class-2-Master is responsible for the diversecommissioning, programming and monitoring functions of modern fieldunits. Related data exchange occurs if required, thus acyclic communica-tion services are used on the Class-2-Master.

The master function is allotted in thismulti-master system in a fixed se-quence: the token-passing procedure.For this purpose, a special message,the “token”, is passed from one activemaster to the next within a logicalring.

This bus access procedure compri-sing the master-slave and token-pass-ing procedures is referred to as a hybrid access procedure.

16

PROFIBUS DP

Passive stations (slave devices) are polled

Active stations, master devices

Class-1 Master

PLC

Class-2 Master

Logical token ring between master devices

2 . PROFIBUS

Figure 7: PROFIBUS network with master and slaves

17

2.2. PROFIBUS AS A “MODULAR SYSTEM”

PROFIBUS is designed on the basisof a modular principle owing to theprovision of various transmission tech-nologies, its versatile communicationprotocol and numerous applicationprofiles. The PROFIBUS modular sy-stem describes the technological ca-pabilities of this field bus type as a whole and thus covers diverse andapplication-specific requirements:■ Horizontal universality:

standard automation technology for differing applications and indu-stries within one system (upstream,mainstream and downstream)

■ Vertical universality:from the field level through to the company level.

From a technological point of view,the PROFIBUS system structure isbased on the ISO/OSI Reference Model (see also Section 1.1.3., Stand-ardization) and consists of specifica-tions of the following basic elements:

Transmission technologyDefinition and description of hardware(physical transmission system)■ Transmission medium:

copper, fiber-optic cable or waveguide, radio

■ Signal level:RS-485, MBP

■ Topology:linear, stubs, star

■ Transmission speed:baud rate (variable and fixed).

Communication technologyDefinition of the PROFIBUS DP pro-tocol via which communication occursbetween the bus users. Three ratingclasses are available for PROFIBUSDP:■ DP V0

cyclic data exchange (process data)

■ DP V1 (incl. V0)acyclic data exchange (useful data)

Figure 8: PROFIBUS modular system

■ DP V2 (incl. V1)additional services (with the focuson drive engineering).

Application profilesCross-manufacturer stipulations ofcharacteristics, performance featuresand behaviors of the devices, e.g.:■ PA Devices

Definition of functions and parame-ters for process devices in processengineering

■ PROFIsaveProfile for safety-oriented applications (SIL)

■ PROFIdriveDefinition of the device behaviorand access procedure for drivesand actuators.

PROFIBUS

Specific application profilesDevice behavior, operation, configuration, programming

Integration technoloyIntegration and operation of the devices

General application profilesCross-application behavior of functions

Communication technologyCross-application behavior of functions

Transmission technologyTransmission medium, connection system, interfaces, network topology

18

Integration technologyDescription of the integration of fieldunits in process control systems andconfiguration tools:■ GSD (necessary)

Electronic Data Sheet (cyclic communication)

■ EDD (optional)Textual Device Description (acyclic communication)

■ DTM/FDT (optional)Device Operating Program (acyclic communication via thestandardized FDT interface).

Modular elements establish the PROFIBUSFrom the user’s point of view, only the elements required for the tasks to be automated are taken from the PROFIBUS modular system. This means the following are selected:■ The appropriate transmission

medium/topology: transmission sy-stem

■ The required protocol rating class:communication system

■ The profile (optional): applicationprofiles

■ The required and optional deviceintegration: integration system.

PROFIBUS is thus presented in theform of various, application-specificfocal points which have not been permanently defined, but which haveproven to be practical in frequent ap-plications. Each focal point is produc-ed by a typical (but not mandatory) stipulated combination of the modularelements of these specified groups.The following examples explain thisprinciple.

2.3. Transmission systems

RS-485The simple and economical RS-485transmission system is mainly used for tasks necessitating a high trans-mission speed without intrinsic safety. A twisted, shielded copper cable with one pair of conductors is used.The bus structure allows non-retro-active coupling and decoupling of stations or step-by-step commission-ing of the system. Subsequent ex-tensions do not affect stations whichare in operation within defined limits.

Network topology RS-485All devices are connected in a busstructure (linear). The transmissionspeed can be selected in the rangebetween 9.6 kbit/s and 12 Mbit/s. It is defined uniformly for all deviceson the bus when commissioning thesystem. Up to 32 bus users may beconnected per segment and the maximum permitted line length is de-pendent on the transmission speed. It is shown in Table 1.

Transmission Rangespeed per segment[KBit/s] [m]

9.6; 19.2; 45.45; 1,20093.75187.5 1,000500 4001,500 2003,000; 6,000; 10012,000

PROFIBUS DP FocusPROFIBUS DP is the variant for production automation; it typically deploys:■ RS-485 as the transmission system;■ the DP communication protocol in

its rating classes; however, gener-ally DP V0

■ one or more optional applicationprofiles typical for production auto-mation, e.g. identification systems or PROFIdrive

■ GSD as integration for purely cyclic communication.

PROFIBUS PA FocusPROFIBUS PA is the variant for process automation, typically with: ■ the MBP transmission system ■ DP V1 communication protocol

rating class■ PA Devices application profile ■ GSD for cyclic data transmission

and, e.g., EDD technology for acyclic data transmission.

PROFIBUS

PROFIBUS DPFocus

e.g. “Ident”profile

GSD

DP protocol

RS-485

➝

➝

➝

➝

Integration

Communication

Transmission

Application

PROFIBUS

PROFIBUS PAFocus

PA Devicesprofile

GSD/EDD

DP protocol

MBP-IS

➝

➝

➝

➝

Integration

Communication

Transmission

ApplicationTable 1: RS-485

19

The start and end of each segmentare provided with an active bus termi-nation, and it must be ensured thatboth bus terminations are constantlypowered in order to achieve disturb-ance-free operation.

Repeaters which connect the individ-ual bus segments must be used in thecase of more than 32 stations or toexpand the network extent. However,a maximum of 126 devices (mastersor slaves) can be connected to a bus(specified address space: 0-125).

MBPThe MBP transmission system (Man-chester Coded, Bus Powered, pre-viously “IEC 61158-2 Physical Layer”)is available for process automation ap-plications involving the requirement forbus powering and intrinsic safety of the devices. Wiring comprises the two-wire system, which means that bothbus communication and the powersupply of the field units use one twistedpair of wires, the bus cable. The “Field-bus Intrinsically Safe Concept” (FI-SCO, see following section), develo-ped specifically for interconnection ofin-trinsically safe field bus devices,substantially simplifies the design andinstallation as compared to the proce-dure conventionally used previously.

Network topology MBPMBP uses synchronous transmissionwith a fixed transmission speed of31.25 kbit/s and Manchester-II coding.

In general, line topologies, lines withstubs or star topologies are possible.These may also be combined. It mustbe noted that a stub may have a maxi-mum length of 30 m in intrinsicallysafe applications. The maximum extentper segment is 1,900 m, but is de-pendent on the application area (ex-plosion group and category) and theline cross-section. One example of atypical application: with instrumenta-tion having EEx ia/ib IIC type of pro-tection, the maximum cable length isapprox. 1,000 m.

The number of users connectable to asegment is limited to 32. However, itis determined by the selected type ofprotection and is typically between 6and 9 devices in the case of intrinsi-cally safe applications. A two-core,screened cable is used as the trans-mission medium. The main bus cableis provided with a passive line termi-nator at both ends. The bus terminatoris already permanently integrated onthe segment coupler or on the link.Reverse-polarity connection of a fieldunit with the MBP system does not

affect operability of the bus since these devices normally feature auto-matic polarity detection.

Wiring information for MBP The intrinsically safe transmission sy-stem MBP is generally restricted to specific sub-segments (field unitsin the explosion-hazard area) of a sy-stem, which are then connected to the RS-485 segment via segmentcouplers or links (Figure 8).

Segment couplers are signal conver-ters which adapt RS-485 signals tothe MBP signal levels and vice versa.They are transparent from the stand-point of the bus protocol. By contrast,links have their own intelligence. Theymap all field units connected in theMBP segment upwards as a singleslave in the RS-485 segment; it actsas master downwards.

Process controlsystem

Visualization/engineering

PROFIBUS

PROFIBUS

RS 485 up to 12 Mbit

C MBP 31.25 kbits

Segmentcoupler/link

Figure 9: PROFIBUS topology

The FISCO modelThe FISCO model (Fieldbus Intrinsi-cally Safe Concept) offers substantialsimplification when planning, wiringand extending PROFIBUS networks in explosion-hazard areas. This modelwas developed in Germany by thePhysikalisch Technische Bundesan-stalt (National Standards Laboratory –PTB) and today is acknowledged,even internationally, as the basic model for operation of field buses in explosion-hazard areas.

If FISCO-approved devices are used,not only is it possible to operate several devices on one line, but thedevices can also be replaced, evenduring operation, by other manufac-turers’ devices or the line can be ex-tended during operation. All this ispossible without complex calculationand without a system certification.That means Plug & Play in the explo-sion-hazard area. All that needs to be noted are the rules for selecting sup-

ply units, line length and bus termina-tions. Transmission in accordance with theMBP and FISCO model is performedin accordance with the following prin-ciples:

■ All bus devices must be approved in accordance with FISCO.

■ In each segment, there is only one infeed source: the segmentcoupler/link.

■ Each field unit consumes a constant basic current of at least10 mA.

■ The cable length may not exceed1,000 m (type of protection i, Category a) or 1,900 m (type ofprotection i, Category b).

■ For all combinations between sup-ply unit and field units, it must beensured that the permissible inputvariables of each field unit (Ui, Ii,and Pi) are greater than the maxi-mum output variables (U0, I0 andP0) of the related supply unitwhich are possible and permittedin the event of a fault.

In addition, for reasons relating tooperational reliability, it must be en-sured that all field units are adequatelypowered. The sum of the current con-sumption of all field units and the FDEvalue must thus lie below the maxi-mum supply current of the supply unit(coupler or link), whereby, in the caseof many supply units, a further 9 mAmust be taken into account for modu-lation of the data signal.

The FDE (= Fault DisconnectionEquipment) ensures that, even in theevent of a short-circuit in one unit, thecommunication of the entire segmentdoes not fail. When calculating, thevalue of the field unit with the highestFDE value must be taken into ac-count.

RS-485-ISThere is major interest among users in also being able to use RS-485 with its high transmission speed in the explosion-hazard area as well.

20

MBP RS-485 RS-485-IS Fiber-optic

Data transmission Digital, bit-synchronous Digital, differential Digital, differential- opticalManchester coding signals to RS-485 signals to RS-485 digital

NRZ NRZ NRZ

Transmission speed 31.25 kbit/s 9.6 to 12,000 kbit/s 9.5 to 1,500 kbit/s 9.5 to 12,000 kbit/s

Data integrity Preamble HD = 4, parity bit HD = 4, parity bit HD = 4, parity biterror fail-safe start start and end delimiters start and end delimiters start and end delimitersand end delimiters

Cable Twisted, shielded Twisted, shielded Twisted, shielded Multimode and single-two-wire line two-wire line two-wire line mode glass fiber, PVC

cable type A cable type A plastic fiber

Remote powering Optionally via the Possible via Possible via Possible via hybrid signal wires signal wires signal wires line

Types of protection Intrinsic safety None Intrinsic safety None(EEx ia/ib) (EEx ia/ib)

Topology Linear and tree Linear topology with Linear topology with Star and ring topologytopology, also termination termination typical, linear topologycombined with possibletermination

Number of users Up to 32 users per Up to 32 users per Up to 32 users per Up to 26 users persegment; total of segment without repeater segment; total of per networkmax. 126 per network up to 126 per network max. 126 per network

Number of Max. 4 Max. 4 with signal Max. 9 with signal Unlimited with signalrepeaters refreshing refreshing refreshing (note signal

propagation time)

Table 2: PROFIBUS transmission systems

Figure 10: Functionalities of PROFIBUS DP rating classes

DP V2■ Data Exchange Broadcast (Publisher/Subscriber)■ Isochronous mode (equidistance)

additional extensions:■ Time synchronization and time stamping ■ HART on PROFIBUS DP■ Up/download (segmentation)

DP V1■ Acyclic data exchange between PLC and field devices

additional extensions:■ Device integration: EDD and FDT■ Portable PLC software function blocks (IEC 61131-3)■ Fail-safe communication (PROFIsafe)■ Alarms

The PROFIBUS International has taken up this task and has elaborateda guide on project planning of intrinsi-cally safe RS-485 solutions with easyinterchangeability of the devices. Theongoing investigations by the testingfacility would lead one to anticipatethat, as is the case with the standardversion, up to 32 users can be con-nected to the intrinsically safe bus circuit.

Optical waveguidesThere are field bus operating condi-tions in which wire-bound transmis-sion systems have their limits, forexample in the case of environmentssubject to strong interference or whenspanning particularly long distances.In such cases, optical transmissionwith optical waveguides is available.

On account of the transmission char-acteristics, star and ring are the typical topology structures, linearstructures are also possible, however. Implementing an optical waveguidenetwork, in the simplest case, is donevia the use of electro-optical transdu-cers that are connected to the devicevia an RS-485 interface as well as tothe optical waveguide. This also en-ables switching between RS-485 andoptical waveguide transmission withina system, depending on the situation.

2.4. Communication sy-stem: The PROFIBUSDP protocol

The PROFIBUS DP (DecentralizedPeripherals) communication protocolis designed for fast data exchange at the field level. This is where centralprogrammable controllers, such asPLCs, PCs or process control sy-stems, communicate via a fast serialconnection with distributed field units

such as I/O, drives or actuators, valves, transducers or analyzers. Data is exchanged mainly cyclicallybetween these units. The communi-cation functions required for this aredefined by the DP basic functions (rating class DP V0).

Beyond these basic functions, DP hasbeen gradually expanded with specialfunctions, aimed at the specific re-quirements of the various application areas, so that DP is available today in three rating classes: DP V0, DP V1and DP V2, with each class featuring a specific focus. This classification pri-marily reflects the temporal sequenceof the specification work, as a conse-quence of the extended requirementsof the applications. Rating classes V0and V1 contain both ”characteristics“(these are mandatory for implementa-tion) and also options, while class V2specifies only options. The most im-portant contents of the three classesare as follows:

DP V0 Makes available the basic functiona-lities of DP. These include cyclic dataexchange and station, module andchannel-specific diagnosis.

DP V1 Contains supplements aimed at process automation, primarily acyclicdata exchange for programming, oper-ation, observation and alarm recoveryof intelligent field units, in parallel withcyclic useful data exchange. This en-ables online access to bus users viaengineering tools. In addition, DP V1contains alarms. This includes, amongothers, the status alarm, update alarmand a manufacturer-specific alarm.

DP V2 Contains further supplements and isprimarily aimed at the requirements ofdrive engineering. Owing to additionalfunctionalities, DP V2 can thus alsobe used as a drive bus for controllingfast sequences of motion on driveaxes. Among others, services includethe following:

■ Slave-to-slave communication(DXB) This function allows direct and,thus, time-saving communicationbetween slaves via broadcast, without having to take the round-about route via a master.

■ Isochronous modeThis function allows clock-synchronous control in master and slaves, regardless of the loading of the bus.

■ Clock controlThis function synchronizes all bus users to a system time.

21

DP V0■ Cyclic data exchange between PLC and field devices

additional extensions:■ GSD configuration■ Diagnosis

Function levels

Time

MD

evic

e ch

arac

teri

stic

s

2.5. Application profiles

Profiles are specifications made bymanufacturers and users on specificcharacteristics, performance featuresand behavior of devices and systems.Profile specifications are aimed atbeing able to operate devices and sy-stems which belong to a profile family on the basis of a „profile-com-pliant“ development, interoperably onone bus as well as exchangeably, upto a certain degree. Profiles allow forapplication and type-specific specialaspects of the field units, controls andintegration resources (engineering).The most important of these are:

PA DevicesThe PA Devices profile defines para-meters and function blocks of fieldunits in process automation, e.g. digi-tal positioners, transmitters and I/Oboxes. These enable interoperabilityand exchange of one field unit withthat of another manufacturer (= inter-changeability). The PA Devices profileis available in version 3.0.

PROFIsafe PROFIsafe defines how safety-relateddevices (emergency stop buttons,light grids, overfilling safeguards, etc.)communicate reliably via PROFIBUSwith safety controls, enabling them tobe used in safety-related automationtasks up to CAT4 in accordance withEN954, AK6 or SIL3 (Safety IntegrityLevel). It implements safe communi-cation via a profile, i.e. via a specialuseful data format and a special, higher-level protocol.

22

Designation Profile content Current statusPUO Directive

PROFIdrive The profile specifies the behavior of V2 3.072devices and the procedures for access V3 3.172to data for variable-speed electrical drives and actuators on PROFIBUS.

PA Devices The profile specifies the characteristics V3.0 3.042of process-engineering devices in process automation on PROFIBUS.

Robots/NC The profile describes how manipulator V1.0 3.052and assembly robots are controlled via PROFIBUS.

Panel Devices The profile describes coupling of V1.0D 3.082simple operating devices and observationdevices (HMI) to higher-level automationcomponents.

Encoder The profile describes coupling of rotary V1.1 3.062encoders, angle encoders and linear encoderswith single-turn or multi-turn resolution.

Fluid Power The profile describes control of hydraulic V1.5 3.112 drives and actuators via PROFIBUS.Cooperation with VDMA.

SEMI The profile describes characteristics of the 3.152devices for semiconductor manufactureon PROFIBUS (SEMI Standard).

Low Voltage The profile defines data exchange for low- 3.122Switch Gear voltage switchgear devices (switch-discon-

nectors, motor starters, etc.) on PROFIBUS.

Dosage/Weighing The profile describes the usage of weighing 3.162and dosing systems on PROFIBUS DP.

Ident Systems The profile describes communication 3.142between devices for identification(barcode and transponders).

Liquid Pumps The profile defines the use of liquid 3.172pumps on PROFIBUS DP. Cooperationwith VDMA.

Remote I/O for Owing to their special position with regards 3.132PA Devices to bus operation, the remote I/Os are provided

with a different device model and different datatypes as compared to PROFIBUS PA Devices.

Table 3: Application profiles (specific)

Figure 11: PROFIBUS integration systems

HART on PROFIBUDS DPIn view of the very large number ofHART devices installed in the field, integrating them in existing or newPROFIBUS systems is an urgent task for most users. The HART on PROFIBUS DP profile offers an open solution for this.

PROFIdrive The PROFIdrive profile defines thedevice behavior and the access procedures to drive/actuator data for electrical drives/actuators on PROFIBUS, from simple frequencyconverters to highly dynamic servo-controllers.

2.6. Integration system

Modern field units provide a diverserange of information and performfunctions which were previously thedomain of PLCs and process controlsystems. Accordingly, in order to al-low open-loop controls or the processcontrol system to achieve smooth cyclic data exchange with field units,it is necessary to declare (“integrate”)the specific parameters and data formats to the field units.

The operating programs for commis-sioning, maintaining, engineering andprogramming these devices require aprecise and complete description ofthe device characteristics. These arethe functions and data of the devices,such as the type of application func-tion, configuration parameters, units of measure, value ranges, limit values,default values, etc.

Methods with which device manage-ment can be standardized have beendeveloped by PROFIBUS for such a device description. The scope of services of these methods are opti-mized for specific tasks, thus the term “structured device integration”is commonly used for this.

23

Cyclic process I/O Acyclic device operation

Acyclic device operation

Application

Acyclic inte-gration in

communication

Cyclic integration

Field units

➝

Inte

grat

ion

M M M MM

Engineering System

EDD DTM

EDS EDS EDS

Electronic Data Sheet (GSD)The GSD is the obligatory “passport”of every PROFIBUS device. It con-tains the characteristic data of the device, information on its communica-tion capabilities and further informa-tion on diagnosis values, for example.The GSD suffices alone for device integration for cyclic exchange of variables and manipulated variablesbetween field unit and programmablecontroller.

The GSD is■ an electronic data sheet provided

by the device manufacturer ■ a simple text description of the de-

vice characteristics for PROFIBUScommunication

■ the basic description for everyPROFIBUS device which needs to be integrated by the engineer-ing system for configuration of the PROFIBUS network for cyclic communication with the PROFIBUS master.

Electronic Device Description(EDD)The GSD alone does not suffice todescribe application-specific func-tions and parameters of complex fieldunits. A more powerful language is required for configuration, program-ming, commissioning, maintenanceand diagnosis of the devices from the engineering system. For this, PROFIBUS has further developed the Electronic Device DescriptionLanguage (EDDL), which was stand-ardized in IEC 61804-2 and withwhich EDDs are generated.

An EDD is■ a text device description

independent of the engineering system’s operating system

■ the description of the acyclicallycommunicated device functions, including graphic capabilities; italso describes device informationsuch as ordering data, materialsand maintenance information, etc.

■ a file developed and provided bythe device manufacturer which isused in addition to the GSD

■ the basis for execution and presen-tation by an EDD interpreter.

The EDD interpreter supplies the datafor visualization with a standard lookand feel extending beyond devicesand manufacturers for the operatingprogram. We can compare it to anInternet browser which interprets thesource code of an HTML page and di-splays it on the screen. Siemens cur-rently offers such an interpreter withthe Process Device Manager (PDM).

24

EDD

Figure 12: EDD interpreter

Device Type Manager (DTM) andField Device Tool (FDT) interfaceIn comparison to the GSD and EDDtechnologies which are based on de-scriptions, FDT/DTM technology is asoftware-based method for device integration. DTM is a software compo-nent for device operation and commu-nicates with the engineering systemvia the FDT interface. FDT/DTM meansthat flexibility and degrees of freedomof software programs can be used for device integration throughout theentire lifecycle.

A DTM■ is a device operating program

which makes the device function-ality (Device DTM) or the com-munication capabilities (Communication DTM) useable

■ features the standardized FDTinterface (Field Device Tool) to aframe application (engineering sy-stem);

■ is comparable to a printer driver,able to run in all FDT frame appli-cations and is programmed on a device-specific basis by the manu-facturer

■ contains an individual user inter-face for each device

■ is used in addition to the GSD.

The FDT interface■ is an open interface specification

developed on a cross-manu-facturer basis (not a “tool” as the name suggests)

■ serves the purpose of open inte-gration of field units of various manufacturers via DTMs in operat-ing programs and, further on, in process control systems

■ defines the interplay between theDTMs and an FDT frame applica-tion in the operating tool or engi-neering system.

Note: Some of the content included in the above-mentioned informationon PROFIBUS originates from publi-cations of the PUO, the PROFIBUSUser Organization. More extensive information can befound at www.profibus.com.

25

Figure 13: FDT frame application

DTM

DTM

DTM

The FOUNDATION Fieldbus is a fieldbus system tailored specifically to theneeds of process automation (e.g. thechemical industry, petrochemical in-dustry and process engineering), thuscorresponding to the PROFIBUS PAfocus.

3.1. Distributed intelligence

The open-loop and closed-loop con-trol functions are implemented jointlyby the controllers and field units, i.e.the application program is distributedover controllers (open-loop controls)and intelligent field units. The applica-tion program is written by combiningfunction blocks. These are run both incontrollers and also directly in the in-telligent field units which, themselves,make available modules of analog anddigital signal processing, such as tim-ers and PID control algorithms, etc.

FOUNDATION Fieldbus devices areconnected to H1 links. The physicalspecification (e.g. the transmissionspeed of 31.25 kbit/s) is described in Standard IEC 61158. The FISCO model (Fieldbus Intrinsically SafeConcept, see also Section 2.3.) wasadded in September 2001 to the profile specifications for the physicallayer of the FOUNDATION Fieldbus.This allows intrinsically safe applica-tion in explosion-hazard environments.

In order to define the application, it is possible (but not absolutely neces-sary) to close a control loop within an H1 link. This loop can then e.g. be put separately into operation and inparallel with other actions, thus reduc-ing commissioning times. Several H1segments are connected via linkingdevices to a high-performance net-work HSE (High-Speed Ethernet)with a baud rate of 100 Mbit/s. The specification allows the devicesto also be connected directly to theHigh-Speed Ethernet (HSE).

26

High-Speed-Ethernet (HSE)

H1 bus

Linking device

AI 101 PID 101

AO 101

…

…

Figure 14: Complete control loop on the basis of FOUNDATION Fieldbus

3 . FOUNDATION Fie ldbus

3.2. The network is the control

Unlike PROFIBUS networks, forexample, no explicit field bus master (e.g. a PLC) is required with FOUNDATION Fieldbus networks. A device (Link Master Device) featur-ing the Link Active Scheduler (LAS)ensures execution of the functionblocks in the right time sequence(scheduling). The Link Active Scheduler presets the time clock onthe corresponding link.

Three mechanisms are available forcommunication between the devices:■ Publisher/Subscriber■ Client/Server■ Report Distribution.

Publisher/Subscriber is buffered 1-to-n communication.Buffered in this case means that onlythe relevant, most recent informationis available on the network. New dataoverwrites the old data. This connec-tion type is used by the field units forcyclic data transfer, e.g. for signal ex-change between the input/output ofthe function blocks.

Client/Server The Client/Server mechanism is usedfor user-initiated, acyclic 1:1 commu-nication between the devices. Typicalexamples of this are set-point adjust-ment functions, alarm acknowledge-ments and uploading and download-ing configuration files.

Report DistributionThe specification itself describes theReport Distribution type of communi-cation. It is used to exchange applica-tion-oriented, acyclic data in a 1-to-nrelation. Examples of this are trend reports or alarm logging functions.

Likewise, the FOUNDATION Fieldbusspecification describes three types ofdevice: ■ Basic Devices■ Link Master Devices ■ Linking Devices, which can be

designed redundantly for ensuringhigh availability.

Link Master Devices are able to assume the role of the Link Active Scheduler (LAS), Basic Devices arenot able to do this. Several Basic Devices and Link Master Devices form an H1 link. Linking Devices linkindividual H1 segments to the HSEbackbone, thus enabling generation of the application distributed over several H1 links (republishing).

27

Zone 1Zone 1Zone 2Zone 2

Distributor Client 1 Client 2

Transmission list

LAS abc

a b c

Val

ue 1

Value 1

Value 1

CD (a)

Field bus

(Publisher) (Subscriber) (Subscriber)

Figure 15: Clocked data transmission in accordance with transmission list

3.3. Link Active Scheduler

The Link Active Scheduler (LAS) controls cyclic data exchange on theFOUNDATION Fieldbus link. It is thepulse generator of an H1 segment. Inorder to be able to perform this task,the LAS receives a list of the trans-mission speeds for all cyclic data andthe information on the processing times of the function blocks of theconnected devices. These times plus additional time blocks, reserved foracyclic communication, determine the (configurable) macro cycle of the application.

The LAS sends the request to trans-mit the device data consecutively toeach user. A device then submits itsinformation (output values of the func-tion blocks) as a broadcast messageto the bus. All other devices can re-ceive and process this data. In addi-tion to cyclic data exchange (cycliccommunication), with the aid of thepublisher-subscriber mechanism, isalso possible to perform acyclic dataexchange (acyclic communication),e.g. for reading and writing parame-ters – client-server communication istypically used for this. Report Distri-bution is used to send large quantities of data.

The LAS also maintains a list of all devices connected to the bus, calledthe Live List. New devices can be added to the busor devices removed from the bus at all times. The live list is updated auto-matically. The LAS assumes the taskof time synchronization of the bus. Forthis purpose, time stamps are sent cyclically. The same time stamp mustbe present in all devices since cyclicdata transfer and execution of thefunction blocks for the application are based precisely on this.

28

Al(1) Al(1)

Al(2) Al(2)

0 20 40 60 80 100 120 140 20 40 60 80 100 120 140

Clocked transmission of the AE(1) and AE(2)

Device 1

Macro cycles

Device 2

Device 3

Device 4

LAS

Non-clocked communication in the gaps of the clocked communication

Schedule cycle n and Schedule cycle n + 1

PID(3) AO(3) PID(3) AO(3)

PID(4) AO(4) PID(4) AO(4)

Figure 16: Clocked actions and non-clocked communication

3.4. The application is produced by functionblocks

The combination of function blocksand the linking of their inputs/outputsdetermine the application, as is familiarfrom PLC programming. The PLC fre-quently uses different field bus typesin order to e.g. connect input/outputsignals from the field or data from intelligent field units connected to PROFIBUS, HART or AS-i systems to its own function blocks.

The specific function block “FlexibleFunction Block” (FFB, also referred toas User-defined Function Block) canbe used to connect the processing logic, i.e. the function blocks of thePLC, to those of the FOUNDATIONFieldbus system. Two types are avai-lable: preconfigured FFBs with a stipu-lated number and type of I/O parame-ters, on which the algorithm can stillbe programmed, and fully configur-able FFBs. These are used for complexapplications and allow both configu-ration of the number and type of I/O parameters and configuration of thealgorithms. They thus allow integrationof control strategies, such as monitor-ing data procurement, batch-process-ing rules, PLC sequential controls,burner management, coordinated dri-ve/actuator control and I/O inter-faces, including gateways to other device networks in the installation.

This procedure of the function blockapplication is used on both specifiedFOUNDATION Fieldbus types H1 and HSE.

3.5. Description and integration of field bus devices

Device Descriptions serve the purpo-se of providing a transparent de-scription of the functionalities of afield unit. They describe the functionblock parameters of the related device.In addition, they ensure Help texts and parameter relationships. Theircontents are written online to ObjectDescriptions, which are filed in theObject Dictionary (OD).

Only when the ODs are combined inVirtual Field Devices (VFDs), is thedata available on the bus. The VFD isthus the view onto the local data inthe device. The actual capabilities of a device (e.g. the number of instanceswhich can be generated for a functionblock) is available online in the deviceor offline in the Capability Files. Theconfiguration tool reads these out andoffers the conventional programmingenvironment for definition of the appli-cation.

NoteSome of the content contained in the above-mentioned information onthe FOUNDATION Fieldbus originatesfrom publications by Mrs. MartinaWalzer.

29

Industrial Ethernet is currently one ofthe most hotly discussed topics inautomation and process engineering.Will Ethernet replace classic field buses or only supplement them?

In itself, Ethernet is not designed fornetworking the field level. For this purpose, technically outstanding fieldbuses are available which are optimal-ly tailored to the requirements of fieldcommunication. So why is the de-mand for Industrial Ethernet so strong-ly expressed nevertheless? It is attributable to the following reasons:

■ Low costs and broad acceptance Ethernet is a worldwide establishedstandard, supported by the IEEEand international standardizationcommittees. Moreover, Ethernet isalso very widespread in office ap-plications.

■ SpeedThe most recent further develop-ments in Ethernet technology in-clude Fast Ethernet and GigabitEthernet. Fast Ethernet (100Mbit/s) is state-of-the-art today.Gigabit Ethernet is considered asthe technology of the future with1000 Mbit/s.

■ Integration with Internet/IntranetAll installed Ethernet networks sup-port communication protocols withsophisticated data transfer andnetwork management characteri-stics. TCP/IP is the most wide-spread thanks to the connection to the Internet and to in-companyintranets.

Isolated control “islands” are thus a thing of the past. Ethernet allowsimplementation of universal com-munication from the field level tothe management level, even span-ning the world.

4.1. Mode of operation

Originally, Ethernet was based on theCSMA/CD procedure (Carrier SenseMultiple Access/Collision Detection).This involves a user wanting to sendobserving the network and starting tosend when the network is free. It canoccur that several users start sendingsimultaneously, since all of them con-sider the network to be free. This colli-sion is detected, all users abort theirtransmission and restart their attemptto send after a randomly controlledtime. This allows a further collision tobe avoided with a high level of proba-bility. This access procedure is non-deterministic in principle since, at

best, statistical statements can bemade for the access options to thenetwork. Against this backdrop, Ethernet has the reputation of beingunsuitable for real-time applications(see also Section 4.2., Real-time capability).

Topology■ Linear structure

Used rarely since communicationbetween individual users or machines is no longer possible if a connective element, link or a connector fails.

■ Star structureA topology in a star structure ismore widespread, but we shouldpoint out that in the event of failureof the central connective element(switches), communication in thenetwork is no longer possible. Thisproblem can be eliminated only ifthe central connective element isdesigned redundantly.

30

Collision

Ethernet

Figure 17: Collision with Ethernet communication

4 . E thernet

■ Ring structure Frequently, the ring structure isused in order to achieve even higher availability. Since 1990, an IEEE Standard (802.1D), withthe designation “Spanning Tree”,has been available for switchoverof redundant links in these ringstructures.

4.2. Real-time capability

If the communication system complieswith the time-related requirements of a specific application, it is – referringto this application – real-time-enabled. In this case, it is assumed that mes-sages will arrive within a specific timeslot and thus the application can becontrolled with adequate accuracy(soft real time). On the other hand, ifthe requirement is that actions mustbe guaranteed and must be performedprecisely at a specific, preset instant,we talk of hard real time.

The following will illustrate that Ether-net, even today, can guarantee a maxi-mum propagation time and can thusbe deterministic.

Collision probabilityIf there is little data exchange in thenetwork, the probability of a collisionis very low. The probability of collisiondoes, however, increase exponentiallywith an increase in data exchange. At a network utilization <10 %, manyapproaches assume that collisionscan be avoided, as it were. On theone hand, the problem is that colli-sions can still occur even if they prob-

ably occur only to a very small extentand that, on the other hand, the band-width used by Ethernet is still verynarrow. This approach to solving theproblem certainly does not representa suitable means of meeting the auto-mation requirements.

Segmentation by means of switchesSegmentation, i.e. splitting networksby means of switches, takes an entire-ly different approach. This enables col-lisions to be avoided completely. Eachnetwork user is connected to the net-work by means of the switch, i.e. onlyquasi point-to-point connections exist,called “Collision Domains”. Besidesthe cost aspect, another crucial factoris that switches are intelligent, analyzethe incoming data packets and for

ward them only in a targeted manner.This results in a far longer latency thanwith pure hubs which, in addition, aresubject to fluctuations, which alwaysmeans time deviations in the form ofjitter.

31

Figure 19: Ethernet switch

Figure 18: Topologies with Ethernet communication

Star structure

Control room 1

Control room 2

Bus structure

Ring structure

Ethernet switchDatabase server

PLC

Database server

Ethernet switch

10/100/1000 MFull-duplex Ethernet

PLC

Communication organization Data exchange between the stationsis organized on the basis of time in order to avoid collisions and make thebest possible use of the existingEthernet bandwidth.

■ Time-slot procedurePurely synchronous communicationwith stipulated time slots with a fixed time slot for each informationitem and each device. Asynchro-nous communication, such asTCP/IP for example, is not possiblein this case since, otherwise, thesampling times cannot be guaran-teed. Such a network must be fullyseparated, as no asynchronousdata exchange is permitted.

■ Time synchronizationSynchronous and asynchronouscommunication on which the de-viations are detected and compen-sated for. A data packet is assig-ned to an instant and TCP/IP communication is possible. Thetechnological backdrop of thisEthernet-TCP/IP-based solution isa procedure based on synchroni-zation of clocks. Useful data is thentransferred asynchronously andprovided with a time stamp. In turn, this data is synchronizedwith respect to the relevant sam-pling instant on the basis of thesynchronized time.

4.3. Automation standards

The availability of real-time-enabledsolutions will be crucial to determininghow quickly and to what extent Ether-net will gain acceptance in automa-tion. This requirement is currently metby five standards, some of which aregrouped under the IAONA umbrellaassociation. These standards are de-scribed below:

■ PROFInet(PROFIBUS user organization)

■ Powerlink(Group of companies: B&R,Hirschmann, Lenze, Kuka, ZHW)

■ Ethernet/IP(ODVA)

■ IDA(IDA user organization)

■ HSE(FOUNDATION Fieldbus).

4.3.1. PROFInetPROFInet was developed with the aimof allowing a process of convergenceof industrial automation with the ITplatform of the corporate managementlevel and global networking of com-panies. PROFInet is a concept for di-stributed automation systems basedon Ethernet and which integrates exi-sting field bus systems – for example PROFIBUS – without modifications.

PROFInet ■ is a solution for distributed auto-

mation: splitting the overall systeminto technological modules. This is implemented by the PROFInetcomponent model

■ assists the integration of simple,distributed peripherals by thePROFInet I/O model. The I/O dataview, known from PROFIBUS, isretained in this case.

32

PROFInet

Component view

One cable, IT services, standard applications, protocols (NRT/SRT), standard controllers, ...

I/O data view

• Distributed automation• System-wide engineering

• Distributed periphery• Familiar I/O view

Component 1 Component 2

Figure 20: PROFInet

Depending on requirements, threecommunication models with differentperformances are offered for PROFInet:■ TCP/IP and DCOM model for

non-time-critical applications■ Soft real time (SRT) for typical real-

time applications in automation (10 ms cycle time)

■ Isochronous real time (IRT) for motion control applications (1 mscycle time).

The acceptance of PROFInet by themarket depends, among other things,on whether existing field bus systemscan be expanded with PROFInet with-out major expense. Field bus systems(e.g. PROFIBUS) can be integrated in two forms (see Figure 21):

■ Integration of field bus units viaproxies: each field unit representsan independent PROFInet compo-

nent whose communication withother components is configured inthe PROFInet connection editor. In this case, the proxy representsall field bus units in Ethernet com-munication.

■ Integration of field bus applica-tions: a field bus segment repre-sents a self-contained PROFInetcomponent whose proxy (e.g. acontrol) contains a PROFInet inter-face. This makes available the entirefunctionality of the subordinate fieldbus in the form of a component onEthernet.

Component modelSystems normally consist of severalsub-units which, in their capacity astechnological modules, act largelyautonomously and coordinate witheach other via a manageable numberof signals for synchronization, se-quence control and information exchange.

The PROFInet component model isbased on such technological mod-ules. These technological modulesconsist of a merging of mechanicalsystem, electronic system and userprogram, i.e. the parts which belongto an intelligent function unit (see Figure 22).Externally, a technological componentinterface is defined to enable commu-nication with other components withinthe distributed system. Only the vari-ables required for interplay with othercomponents are accessible at theinterface. In the case of systems engi-neering, the communication relation-ships between the components andtheir devices are defined by intercon-necting links between the componentinterfaces to a specific application.

33

Controller

Ethernet

PROFIBUS DP Fieldbus

Distributed I/ODP slaves

IntelligentDP slave

IntelligentDP slave

Proxy

Mechanical

FillingIntelligentfield service

Control-software

Figure 21: PROFInet architecture

Figure 22: Component view

The PROFInet components generatedare interconnected to an applicationwith the PROFInet connection editorby clicking with the mouse from a library. Interconnection replaces pro-gramming of the communication rela-tionships, which was previously verytime-consuming, with simple graphicconfiguration.

PROFInet I/OThe PROFInet component model issuitable for intelligent field units andprogrammable controllers. Simplefield units are described in PROFInetby the I/O view, similar to PROFIBUSDP. This also integrates the distribut-ed periphery in PROFInet. The es-sential feature of this integration is theuse of distributed field units with theirinput and output data, processed inthe PLC user program.

PROFInet I/O offers protocol elementsfor the following functions: ■ Cyclic transmission of

productive data ■ Acyclic transmission of alarms■ Acyclic transmission of process

and diagnostic data.

The basis for the definition of PROFI-net I/O is the device model standardi-zed in IEC 61158. The specificationwas made allowing for the followingrequirements: simple conversion of acontemporary PROFIBUS DP device(master or slave) to a PROFInet I/Odevice (I/O controller or I/O device)and, wherever possible, the same userview onto the I/O devices as are to-day onto PROFIBUS DP slaves (froman engineering viewpoint, HMI, userprogram, OPC server, …).

Real-time communicationSoft real time (SRT)In order to be able to comply withreal-time requirements in automationdown to cycle times of 10 ms, Version2 of PROFInet specified an optimizedreal-time communication channel based on Ethernet (Layer 2). Such a solution reduces run times in thecommunication stack and achieves a performance enhancement with re-spect to the updating rate of automa-tion data.

Isochronous real time (IRT)Isochronous real time is available with the future version of PROFInet,Version 3 (2004). PROFInet thuscomplies with the hard real-time re-quirements of motion control appli-cations (150 axes with cycle times of 1 ms and jitter down to 1µs).

4.3.2. PowerlinkThe aim of developing Ethernet Pow-erlink was to use standard Ethernettechnology under adverse real-timeconditions in automation engineering.In addition to using commercially avail-able components and ensuring trans-parent data exchange at all networklevels, the aim was to guarantee a uniquely predictable time response in the communication between all sy-stem sections.

The objective is to network each de-vice – from the open-loop control, tohighly dynamic drive/actuator controlsystems through to the I/O level – bymeans of a standard Ethernet con-nection under time-critical or conven-tional conditions.Widespread Internet services, such as web browsers or ftp file exchanges,should be available in both cases.

ImplementationTargeted use of Ethernet Powerlink inautomation of machines and systemsallows isolated consideration of time-critical data exchange in a local areanetwork. Coupling with the convention-al company-wide network can bedone using a bridge. This separationavoids unforeseeable collisions withdevices without Ethernet Powerlink.Under reduced real-time conditions,Ethernet Powerlink devices can alsobe operated in a network without separation.

ProtocolData exchange is organized strictly bymeans of time-slot procedures, SlotCommunication Network Management(SCNM).

The TCP/UDP/IP protocol stacks arereplaced by the real-time-enabled Powerlink stack. One of the stations in the Ethernet Powerlink network as-sumes the manager function, whichcontrols communication and presetsthe time clock for synchronizing allusers. All other stations (controllers)send only if they receive the corre-sponding authorization from the mana-ger. The data can be received by allother stations (broadcast).

34

Data exchange in the network runs in deterministic, isochronous cycles. The cycle time can be configured inthe manager.

Owing to Slot Communication Net-work Management, the maximumnumber of users in the Ethernet Po-werlink network is dependent on theset cycle time. However, it is rarelynecessary for all users to send time-critical data in each cycle. Example: in the case of a drive/actuator coup-ling, the master axis transmits positionand reference variables in each cycle.A slave axis will generally receive re-ference variables and will only occa-sionally need to send its own statusinformation. Consequently, two clas-ses of user are defined in the Ethernet Powerlink:

■ Class 1 – cyclic: user sends ineach cycle.

■ Class 2 – prescaled: user sendsonly every nth cycle. The maximumnumber of Class-2 slots per cyclecan be programmed and is de-termined by the cycle time and thenumber of Class-1 stations. Accordingly, this results in the“prescale cycle”.

Ethernet Powerlink in an Internetnetworked systemUse of Ethernet in automation is pri-marily intended to provide flexibilityand universal communication from thecoordinating level to the I/O level, without geographic or system-relatedlimits, on the basis of the Internet pro-tocol (IP). This has also been allowedfor in the implementation of EthernetPowerlink:

■ Cyclic and acyclic Ethernet Powerlink communication

■ Transparent transmission and re-ception of Standard Ethernet Fra-mes in the acyclic part. The func-tion calls of the API drivers ofEthernet Powerlink are compatiblewith Standard Ethernet drivers. Allprotocols or applications at higherlevels, such as TCP or UDP (UserDatagram Protocol), can thus bebased on it without modification. In addition, an Ethernet Powerlinkstation can be operated via thesame connection in a conventionalEthernet network in Basic Ethernetmode. This is useful in the case of non time-critical applications,such as programming, parameterassignment and testing of thesedevices. In this connection, anEthernet Powerlink mode for softerreal-time conditions is currently in preparation.

TopologiesIn the case of Ethernet Powerlink, thesame topologies are possible as withFast Ethernet, i.e. up to 100 m seg-ment length and use of Cat. 5 patchcables. Use of optical waveguides isalso possible. Network topologies areimplemented with the aid of hubs. No collision detection is required sincethere is no collision in an Ethernet Powerlink network and there are notopology restrictions in the case ofhub cascading.

Ethernet Powerlink specifies up to ten hubs in one communication path.Field units generally have an integratedhub so as to simplify the structure.

Use and standardizationThe fact that Ethernet can be usedeven under adverse real-time condi-tions is proven by diverse industrialapplications: these extend from injec-tion-molding machines with three axeswith a 400 µs cycle time to packagingmachines with 19 axes with an 800µs cycle time, through to large-scaleinstallations with a synchronization of50 axes and 50 I/O stations within2.4 ms. New communications stand-ards are always only as useful as theextent to which they are used. That iswhy B&R (Bernecker + Rainer) openlyreleased the source code of theEthernet Powerlink protocol. Indepen-dent institutions such as the ZurichWinterthur Technical College (ZüricherHochschule Winterthur – ZHW) and companies such as Hirschmann,KUKA Roboter or Lenze are advanc-ing further standardization togetherwith international standardizationcommittees in order to make availableon the market as many terminal de-vices of different manufacturers as possible with Ethernet Powerlink inthe shortest possible time.

35

ApplicationApplication

IPIP

Media Access ControlEthernet CSMA/CD

TCP

PowerlinkSCNM

UDP

Media Access ControlEthernet CSMA/CD

TCP UDP

Figure 23: Powerlink system structure

4.3.3. Ethernet/IPIn early 1998, a special interest groupof ControlNet International defined aprocedure for basing the CIP applica-tion protocol (see Section 5.4., De-viceNet), already published within theframework of ControlNet and Device-Net, on Ethernet. On the basis of thistechnology, ControlNet International(CI) and the Open DeviceNet VendorAssociation (ODVA) presented Ether-net/IP in March 2000, with the assist-ance of the Industrial Ethernet Asso-ciation (IEA).

Ethernet/IP is an open network since it ■ is based on the IEEE 802.3

standard■ supports the widespread TCP/IP

protocol family ■ allows control applications with

the Control & Information Protocol(CIP), which is used as an appli-cation protocol for real-time I/O.

CIP offers a broad scope of standardservices for access to data and con-trol of networked devices via “implicit”and “explicit” messages.■ CIP uses implicit messages for

regular cyclic data exchange inwhich the stations involved areaware of what data is expected:very compact, pure data block with little overhead, typical I/O data via I/O connections.

■ All individual messages which are sent only once use the explicittype. This relates, for example, toall request/response messagesbetween client and server.

Basically, Ethernet/IP can be consider-ed as an industrial expansion of Ethernet TCP/IP, since the actual CIPmessages from the application layerare “packed” as user data in theTCP/IP frames by means of encapsu-lation. This means that an applicationcan send its data to another applica-tion via Ethernet: a CIP message isgenerated by the application automa-tically if necessary and converted byencapsulation to a normal TCP/IP package – comparable to an envelopeinto which a letter is inserted. This packed message is then routed viaEthernet to the destination devicewhere, after reception, this messageis routed by the TCP/IP protocol backto the encapsulation protocol wherethe message (the original CIP mes-sage) is unpacked again (taken out ofthe envelope) and routed via CIP tothe receiver application. This directapplication link is, in principle, possi-ble between all users with CIP appli-cation protocol – even if they origi-nate from different manufacturers orare located on different networks. This means that, via TCP/IP, Ethernet/IP can send “explicit messages” –

36

as the message telegrams which contain both the precise protocol in-formation and instructions for furtherhandling in the data field are called.The receiver must interpret explicitmessages as an instruction, executethe corresponding instruction and generate a response to it. This ver-satile method of data communicationis used e.g. for device configuration, device programming and device dia-gnostics with varying quantities ofdata. As a connection-oriented trans-port protocol with secure end-to-endcommunication, TCP is also optimallysuited to such applications.

However, real-time communicationmakes quite different requirements. In this case, Ethernet/IP does not useTCP either but UDP via IP (InternetProtocol). This protocol is essentiallymore compact and thus also supportsso-called “multicast” messages (si-multaneous reception by severalusers) and is used by Ethernet/IP forsending the so-called “implicit mes-sages”. On these message telegrams,the data field no longer contains pro-tocol information but only real-time

Control and Information Protocol-CIPCommon Object LibraryCommon Device ProfilesCommon Routing

CAN CTDMA TCP/UDP/IP

Ethernet802.3(CSMA/CD)

OtherProtocols(HTTP, FTP,SMTP, etc.

Application_7

Presentation_6

Session_5

Transport_4

Network_3

Data Link_2

Physical_1

SNMP,FTP, SMTP,Telnet,HTTP, etc.

TCP, UDP

IP, ARP

CSMA/CD, Ethernet frames

Figure 24: System structure of Ethernet/IP

I/O data. The receiver application al-ready knows how to interpret this datasince this has already been negotiatedduring connection set-up. So implicitmessage telegrams run via an existingvirtual connection between the usersand are constantly refreshed cyclicallyat short intervals with new, up-to-datedata and I/O signals. The overhead in this case is minimal so that thesemessages can be processed veryquickly and with priority – just the requirement for time-critical controltasks.

Thus, Ethernet/IP combines TCP/IPand UDP/IP data telegrams for trans-port of the packed explicit and implicitmessages, which means that, in thiscase, both real-time I/O data for time-critical control tasks (UDP) and inform-ation data (TCP) on a network can

be used in parallel. Ethernet/IP is thusideally suited to I/O control, configu-ration and diagnostic tasks and dataacquisition in industrial environments– particularly if we consider the inter-operability and exchangeability of aninternational standard for automation.

Since ControlNet, DeviceNet andEthernet/IP feature the same appli-cation protocol, they can also accessjoint device profiles and object librar-ies. These objects allow plug & playinteroperability between complex devices of different manufacturers.The object definitions support trans-mission of real-time I/O messages,configuration data and diagnosticdata and acquisition of data via thesame network. This means that theuser can easily set up communicationlinks to intelligent devices such as dri-ve/actuator and robot controls, barcode readers and weighing sy-stems, etc., without having to take re-course to specific software tools. Theresult: being faster online with full diagnostic support.

In addition, Ethernet/IP supports thecombination of acyclic data transmis-sion (explicit messages) with cyclicallytransmitted control data (implicit mes-sages). Thanks to the producer-con-sumer characteristics assured by theControl & Information Protocol CIP,Ethernet/IP can now support everycommunication mechanism importantfor device networking – from cyclicpolling to time-driven or event-driven

triggering through to multicast or simple point-to-point connections fordata coupling.And, finally, the relatively high accep-tance of ControlNet and DeviceNet isalso important, since approx. 400 manufacturers worldwide havecurrently already developed over 500different interoperable products forone of these networks. Combiningand supplementing these networkspractically produces a single, universalsystem (same application layer) andsupport for Ethernet/IP is remarkablyhigh among this group of manufactu-rers as well.

37

4.3.4. IDAIDA (Interface for Distributed Automa-tion) is a standard for distributed in-telligence in automation engineering.The aim is to achieve an interplay oftools and devices in a non-hierarch-ical network in which each user cancommunicate freely and in real timewith every other user at any time. IDA includes:

■ Ethernet TCP/IP and Web techno-logies

■ All communication services andinterfaces to devices and software

■ Interoperability of an extremelywide variety of manufacturer devices

■ Horizontal integration – commu-nication without interfaces or theneed for programming

■ Vertical integration – connection ofproduction to corporate IT and theInternet

■ Safety on Ethernet integrated inthe concept.

The IDA standard covers software,hardware (devices and descriptions of their characteristics) and communi-cation. IDA includes all programmablecontrollers and does not even stop atcorporate IT. Whenever standards can be used, IDA integrates these intoits own standard. This is the case, forexample, with FTP and http Internetprotocols and others, as well as OPCfrom the automation platform.

The aim is to operate an extremelywide variety of manufacturer softwareand devices in one common networkwith distributed intelligence. Thesecan then be integrated in the networkvia plug & play.The scope of devices covered includ-es a very broad range of devices,such as PLCs, soft PLCs, drive con-trollers, remote I/Os and operatingdevices. Any IDA-compatible tool can be selected for programming.

By far, the majority of devices world-wide communicate via industrialEthernet with Modbus TCP/IP. TheIDA Group has opted to closely co-operate with the Modbus user groupand is incorporating Modbus in theIDA standard as a quasi-standard inEthernet communication in the field ofautomation engineering. The benefitsof IDA for the user are very diverse.These benefits can be very roughlybroken down into the advantages of horizontal integration and vertical integration.

38

Figure 25: Distributed intelligence

Figure 26: System structure of IDA

Application 1,e.g. PLC

Application 2,e.g. CNC

Application 3,e.g. visualization

iDA communication layer

iDA

Virtual control

Applications

API

IDA Object Model

ModbusTCP

Opticalconnector

P/SNDDS 3.0

UDP

C/SMessaging

TCP

IP

Ethernet

Boot P+

DHCP

Web

HTTPServer

FileTrans

FTPServer

Mail

SNPMClient

Benefits of horizontal integration:

■ System modularityDistribution of intelligence over the devices, the diverse possible topo-logies and distribution of the system program over the network users provide entirely new capabili-ties in system modularization.

■ Device integration All device descriptions are archiv-ed in the devices. This facilitatesintegration in the software tools.Manual configuration is not requiredwhen exchanging devices.

■ ProgrammingThere is no programming necessary for the communication relation-ships between the devices. Sinceall components involved communi-cate with each other in real time, itis possible to ignore the physicalarrangement of the various func-tions when writing the program.

■ Commissioning and maintenanceThe entire system can be monitoredfrom any location in the installationthat has network access. This sy-stem-wide overview substantiallyfacilitates fault-finding.

■ Safety system No special safety infrastructure isrequired. Safety-related sensorsand actuators are able to commu-nicate with each other directly. Thesafety PLC is distributed over thesecomponents. A concept reviewconducted by the German Techni-cal Inspection Authority (TÜV) inaccordance with Category 4 andSIL 3 was passed successfully.

■ IntegrationIDA systems are able to interworkwith existing field buses withoutlong-drawn out adaptation via anetwork-independent data link layer.

■ Development effort and expenseDevice manufacturers no longerdiffer by virtue of network techno-logy or protocols, but by devicecharacteristics and software tools.There is no need for developmentof different field bus componentswith an extremely wide variety ofprotocols.

One justified demand is integration ofindustrial communication in corporateIT. This results in important advan-tages for the user:

■ TransparencyEach intelligent device features itsown homepage. If adequate perfor-mance or storage capacity is notavailable, the devices are integratedin the IDA concept via the server.This enables monitoring, alarm handling, polling of production dataand operation of the entire systemto be performed from any operatingstation using a standard web brow-ser.

■ Remote accessIt is possible to access all systemdevices, programs and parametersusing a standard web browser. Allinformation can be downloadedwith the standard Internet protocolFTP.

■ UniversalityEach application and task can access the corporate database directly in order to read and writeproduction data. This creates thebridge to business software byinterworking with ERP and MESsystems.

39

4.3.5. High-Speed-Ethernet(see also Section 3, “FOUNDATION Fieldbus")

The specification work for the FOUNDATION Fieldbus (FF) com-menced in 1994 and was aimed at a field bus for process automation.The H1 variant was initially implement-ed, which at 31.25 kbit/s was veryslow, but which sufficed for the pro-cess-oriented area.

However, in light of the increasing di-scussion about industrial Ethernet, a decision was made in 1998 in favorof the supplementary specification ofa protocol on the basis of Ethernet,which was to be suitable as a back-bone for H1 networks, but also as apure Ethernet-based field bus: HSE(High-Speed Ethernet).

Systems and principle of operationThe FOUNDATION Fieldbus is notonly a field bus, but rather an archi-tecture for distributed automation sy-stems specifically aimed at processautomation. HSE allows fast informa-tion transfer with remote I/Os andbetween PLC, PC and process con-trol systems. HSE is also suitable forcoupling several H1 segments.

The field units are considered functionblocks with a permanently definedfunctionality at application level. Themodel of the FOUNDATION Fieldbuscomes in at this level of consideration.The task is thus to interconnect, program and manage function blocks,whereby these function blocks are not concentrated in one unit as in aPLC, but are distributed over manydevices in the system.

From this, we can derive the followingfunctionalities and architecture fea-tures:

■ The distribution of application func-tions over different devices requiresnot only standardization of commu-nication, but also standardization offrequently required standard func-tions in the form of predefinedfunction blocks. This ensures inter-operability and exchangeability ofdevices.

■ The distributed function blocks mustbe provided with communicationlinks in accordance with their logicalinterconnection.

■ The distributed function blocks mustbe started and synchronized in ac-cordance with the logically correctexecution sequence within a globalcycle. This necessitates functionsfor time synchronization and for di-stribution of schedules on the basisof which transmission of data andexecution of function blocks aresynchronized network-wide.

■ Engineering of continuous proces-ses which cannot simply be switch-ed off necessitates methods for incremental modification duringoperation. Functions of system ma-nagement and network manage-ment are available for this. Whenspecifying HSE, an attempt wasmade to take recourse to existingprotocols to the highest possibleextent. This is why many TCP/IPsuite protocols are used, such asTCP and UDP as transport proto-cols, IP as network protocol, SNTPfor time synchronization and SNMPfor management of Ethernet de-vices. This means that HSE, up tolayer 4 (see also Section 1.1.3.,“Standardization”), does not differfrom the other Ethernet-basedautomation concepts such asPROFInet or Ethernet/IP.

40

HSE

Host

HSE

HS

E

Switch

H1H1

Linking Device Ethernet Device

Figure 27: System structure of HSE

Even with FF HSE, the time-provenfunctions of system management andnetwork management known from FFH1 are available, and they enablecomplete engineering of all devicesexisting in the system online. Extend-ing beyond pure communication, theFOUNDATION Fieldbus also stand-ardizes the application in the form offunction blocks. There are resourceblocks, function blocks and transducerblocks.

Each device features precisely one resource block which contains device-specific parameters such asmanufacturer and device type. Func-tion blocks represent modular appli-cation functions such as analog input,analog output or PID controller. Theyare standardized both in regards totheir interfaces and their behavior. A distributed application is producedby interconnection of the functionblocks.

In the event of required applicationfunctions not yet included in the FFfunction block set, freely programm-able devices, such as open-loop controls, can be defined as flexiblefunction blocks and integrated into an FF network.

Topology and device classesThe topology of FF High-SpeedEthernet results from the system to-pology and the architecture principlethat the field units (specifically in theintrinsically safe area) are operated onH1 bus segments which are connect-ed via gateways to Ethernet. This leads to four different classes of device:

■ Host Devices are PCs or processcontrol systems with Ethernet con-nection which, themselves, do notcontain function blocks or manage-ment objects in accordance withthe FF specification, but whichcommunicate with HSE devices viaEthernet. In addition, there may bea Time Publisher which distributesthe system-wide time via the Sim-ple Network Time Protocol (SNTP).

■ (Field) units which are connecteddirectly to Ethernet are referred toas Ethernet Devices. The previously mentioned, predefin-ed function blocks may be used asstandardized applications of suchdevices. However, there is also a flexible function block which isfreely programmable in accordancewith IEC 61131 – and this is particularly interesting for HSE: a PLC as Ethernet component inthe HSE network.

■ FF networks interwork with H1 networks via Linking Devices.“Third-party” field buses can beconnected via foreign I/O gate-ways.

Real-time capabilityThe discussion in respect to the real-time capability is not as intense withFF HSE, as it is in the sector of pro-duction automation. Firstly, the cycletimes in process automation are rela-tively slow (> 100 ms) and secondly,the bandwidth of HSE (100 Mbit/s) is higher by a factor of 3,000 than H1nominally and should thus also sufficefor networking many H1 segments viaEthernet. Finally, exchange of produc-tive data via HSE is linked to cyclicexecution of the function blocks andis thus centrally planned, which sub-stantially reduces the probability ofcollisions since this acts in the sameway as a subordinate time-slot proto-col.

41

The CAN bus was developed in co-operation with the Robert Bosch andINTEL Semiconductor companies. 12 years after the first CAN protocolcontroller chips (INTEL 82526) be-came available, the increasing use ofCAN in all application areas continuesat a rapid pace. Besides being de-ployed in passenger cars and com-mercial vehicles, in addition to mobilesystems of all types (e.g. public trans-port vehicles, elevators, ships, rail-ways, special vehicles, aircraft, etc.),the Controller Area Network (CAN) isused to a constantly increasing extentin virtually all sectors of industrialautomation engineering for network-ing programmable control units withintelligent input and output devices,sensors and actuators, but also in di-verse special applications such asmedical technology.

This has applied in particular since the availability of higher protocol stand-ards and profiles for CANopen andDeviceNet. These solutions of com-parable functionality provide standar-dized, distributed applications for sy-stem implementation. Standardizedcommunication mechanisms, identifierassignment, network managementfunctions and device profiles allowinteroperability and exchangeability ofdevices of different manufacturers.

CANopen was specified by the CAN-in-Automation (CiA) user organizationand DeviceNet was specified by theRockwell Automation company. Con-sequently, CANopen is used predomi-nantly in Europe and DeviceNet isused predominantly in the USA andAsia.

42

Boost pressure

Air pressure

Oil temp.

Engine temp.

Oil pressure

Temperature

Pressure

Alarm

CAN-BusTerminating resistorTerminating resistor

Diagnostic-interface

Ignition

InjectionMeasure-ment 1

Node 1

Measure-ment 2

Node 2

Display

Node 4

System monitoring

Node 5

Engine timing

Node 3

10045

102050

100200

50010001600

Dat

a ra

te/k

bit/

s

50 100 200 1000 10000 Line length/m

Figure 29: Basic structure of a CAN network

5 . CANCANopen/ DeviceNet

Figure 28: CAN network using the example of automotive engineering

5.1. Mode of operation

CAN is a multi-master network. Eachuser can actively access the bus withequal priority. Unlike other protocols,CAN uses object-oriented address-ing. The users are not provided withan address, but the message transferr-ed is identified with an identifier, sti-pulated network-wide, as the sourceaddress. A user must filter the mes-sages relevant to it from the messagestream available on the bus.

This identifier represents the name ofthe message in coded form, e.g. themeasured value “Engine Temperature”.It also contains the priority of themessage. The following applies: thelower the identifier, the higher thepriority. Bus access is controlled onthe basis of this priority.

5.2. Topology

The bus system is designed with a linear structure. The achievable baudrate depends on the network extentand is up to 1 Mbit/s with 40 m buslength. On the other hand, up to1,000 m cable length can be imple-mented with 50 kbit/s (see Figure28). The maximum length of a linebranch (stub) is defined at 0.3 m.

The number of nodes per network is 2 to 30, but can also exceed 32 de-pending on design of the bus inter-face. Data transmission is performedprimarily via a twisted two-wire line.Figure 29 shows the basic structureof a CAN network.

5.3. Bus access procedures

Each user has equal priority and cancommence transmission of a messageas soon as the bus is no longer busywith other telegrams. This means thatbus access with CAN protocol is ran-dom and not stipulated by definedcommunication sequences (token orpolling).

This means that several users can simultaneously request bus access.With other random bus access pro-cedures, this results in destruction ofthe connected messages as the resultof superimposition of the telegrams,and all users wishing to send must retry to access the bus after a shortwaiting time.

CAN protocol ensures that the mes-sage with the highest priority prevailsover its lower priority competing message. If two or more users wish to use the bus simultaneously, a selection phase (bit-serial arbitration)decides which user may send its message. The other nodes wishing to send abort their message and retry after the next bus idle time (CSMA/CA procedure).

Figure 30 below shows the principleused for bus arbitration. Each usermonitors the signal level on the busduring the arbitration phase. The arbitration phase covers trans-mission of a message identifier andtransmission of the RTR bit. If a net-work node detects a dominant bus level (dominant bit) even though it itself has sent a recessive level (recessive bit), it immediately abortsthe send operation, since this indicatesthat a message of higher priority isobviously being sent simultaneously,and reverts to receive state. Since amessage is sent with each bus ar-bitration, the procedure guarantees“loss-free” bus access.

43

41 2 3

Control field,user 3

Control field, user 3

Data field, user 3

Data field, user 3

User 1

User 2

User 3

Arbitration phaseBus level

Identifier Controlfield

0…8 bytes Data field

SOF

RTR10 9 8 7 6 5 4 3 2 1 0

Figure 30: Bus access procedures

5.4. International stand-ardization: CANopenand DeviceNet

CAN complies with the ISO/OSI 7-layer model (see also Section 1.1.3.,“Standardization”) and essentially specifies only layer 2. The standarddescribes only the dominant/recessiveprocedure for the transmission link and physical bus connection. This means that several variants exist forspecific implementation:

■ CANopen: CAL (CAN ApplicationLayer) of the CAN-in-Automationuser group (CiA)

■ Rockwell Automation DeviceNet

CANopen A standardized application for distri-buted industrial automation systemson the basis of CAN and CAL com-munications standard has been defin-ed with the CANopen profile family.CANopen is a standard of CAN-in-Automation (CiA) and became verywidespread shortly after it was madeavailable. In Europe, CANopen can beconsidered the authoritative standardfor implementation of industrial CAN-based system solutions.

The CANopen profile family is basedon a “communication profile” whichspecifies the underlying communica-tion mechanisms and their descrip-tion. The most important device typesused in industrial automation engineer-ing, such as digital and analog input/output modules, drives, actuators,operating devices, controllers, pro-grammable controllers or encoders,are described in "device profiles”. The device profiles stipulate the functionality of standard devices ofthe relevant type.

Configurability of devices via the busforms the basis for the manufacturerindependence striven for with the profile family.

The central element of the CANopenstandard is the description of the device functionality via an “object directory” (OD). The object directoryis subdivided into an area which con-tains general information on the device,such as device identification, manu-facturer name, etc., communicationparameters and a part which describ-es the specific device functionality.

Functionality and characteristics of aCANopen device can be described in ASCII format in the form of a stand-ardized “Electronic Data Sheet” (EDS).In this case, the EDS must be seen as a type of form. The actual devicesetting is described with the “DeviceConfiguration File (DCF)”. EDS andDCF may be made available in theform of a data medium which can beretrieved via the Internet or which isstored in the device.

Analogous to the other known field bussystems, CANopen distinguishes between two fundamental data trans-mission mechanisms: fast exchange ofshort process data via "Process DataObjects” (PDOs) and access to entriesof the object directory via “ServiceData Objects” (SDOs).

The latter primarily serve the purposeof transmitting parameters during device configuration and, generally,for transmission of long data areas.Process data objects are generallytransmitted event-driven, cyclically orupon request, as broadcast objectswithout additional protocol overhead.

DeviceNet DeviceNet was developed by Rockwell Automation as an open fieldbus standard based on the CAN protocol. Designed as a high-perfor-mance protocol for automation engi-neer-ing, it plays a leading role todayin the USA and Asia. In Europe as well,system solutions are being implement-ed with DeviceNet to an increasingextent.

44

Communication-interface

Object directory Application process

Logical addressingscheme for accessto communicationand device parame-ters, data and func-tions

Device functionsServer SDOs

Client SDOs

Rx PDOs

Tx PDOs

NMT, SYNC,Emergency,Time StampMessages

c C c C

ccc

ccc

Pro

cess

I/O-s

igna

ls

CA

N-B

us

Figure 31: System structure of CANopen

The ODVA, in its capacity as the or-ganization of all DeviceNet users, isresponsible for specifying and updat-ing the DeviceNet standard. In addi-tion, the ODVA also works on world-wide propagation of DeviceNet. Thecurrently available Version 2.0 of thestandard contains certain functionalextensions and corrections.

DeviceNet is an open protocol andwithin the various Special InterestGroups (SIGs), each ODVA membercan cooperate in the further develop-ment of this standard. DeviceNet isone of three open network standards(DeviceNetTM, ControlNetTM andEthernet/IP) which all use a commonapplication layer (ISO Layer 7), the“Control and Information Protocol”(CIP). In the future, this common application layer and open software and hardware interfaces will enableuniversal connection of field level automation components to the Internet. The “Control” share of the CIP definesthe exchange of I/O data in real timevia I/O messages (I/O Messaging orImplicit Messaging). The “Information”share of the CIP defines exchange of

general data for configuration, diagno-sis and management via explicit mes-sages (Explicit Messaging). These two message types provide optimum communication for industrial controls. CIP thus provides the user with fouressential functionalities:

■ Standard control services ■ Standard communication services■ Standard distribution of messages ■ Common knowledge base.

The DeviceNet protocol is designedas a simple, low-cost, but high-perfor-mance protocol at the lowest field buslevel, i.e. for networking sensors, actu-ators and related open-loop controls. The bandwidth of the devices whichcan be connected via DeviceNet ex-tends from the simple light barrier tothe complex vacuum pump for semi-conductor production.

Up to 64 nodes with baud rates of125, 250 or 500 kbaud can be oper-ated in a DeviceNet network. The devices can either be powered via the DeviceNet bus or feature theirown power supply.

The main application area of Device-Net is factory automation. Comparedwith CANopen, DeviceNet offers approximately the same functions, butwith differing points of emphasis.

For example, network management in DeviceNet is accommodated in di-stributed fashion in each node. Thuseach node monitors the others. In thecase of CANopen, there is a centralinstance for this, the NMT master. The communication mechanisms un-der CANopen are simpler and there-fore the devices are less complex. By contrast, DeviceNet offers greaterreliability in application of the proto-col, but also necessitates more re-sources.

Features of CAN■ Linear structure, extent dependent

on transmission speed (40 m at 1Mbit/s; 1,000 m at 50 kbit/s)

■ High data transmission speed upto 1 Mbit/s

■ Multi-Master function■ Object-oriented messages, multi-

casting and broadcasting with acceptance check

■ Bit-serial arbitration and prioritycontrol by CSMA/CA bus access

■ Short response times, real-time-enabled for prioritized users ineach case

■ Number of users limited only by theperformance of the driver modules

■ High data integrity, network-widedata consistency and deactivationof defective stations.

45

ApplicationObjects

ParameterObject

AssemblyObjects

Message RouterObject

IdentifyObject

DeviceNetObject

Figure 32: DeviceNet system structure

I/O connectionsExplicit Messaging

Connections

The fast bus, particularly for appli-cations in production automation.

INTERBUS operates with a master-slave access procedure, whereby the bus master simultaneously imple-ments the coupling to the higher-levelcontrol or bus system. From a topologystandpoint, INTERBUS is a ring sys-tem, i.e. all users are actively coupledin a self-contained transmission path.Sub-ring systems may be formed forstructuring the overall system with theaid of bus terminals on the main ringoriginating from the master.

One special aspect in comparison toother ring systems on the INTERBUSsystem is that both the outward dataline and the return data line are routedwithin one cable and through all users.This results in the appearance of a linear or tree structure. A widespreadform of the physical layer of theINTERBUS system is based on theRS-422 standard with twisted-pair lines.The INTERBUS cable requires five wires between two devices, due tothe ring structure and the fact thatthere is also a compensating line.

Owing to the RS-422 point-to-pointtransmission, a distance of 400 mbetween two devices is possible at adata transmission speed of 500 kbit.Thanks to the integrated repeaterfunction in each user, it is possible to achieve an overall extent of theINTERBUS system of up to 13 km. Up to 512 users can be connectedper INTERBUS network.

46

Figure 33: INTERBUS topology (topologically: ring system, physically: bus tree structure)

PLC

Type 8630

Type 8644 with WAGO interface

Typ 8644 with WAGO interface

Type 8644 with WAGO interface

Type 8640

Branch terminal,system coupler

Cable cross-section

6. INTERBUS

6.1. INTERBUS topology

Due to the point-to-point structure,conversion from copper cable to opti-cal waveguide with standard convert-ers can occur at any point along the(RS-422) bus line. Thus, self-control-ling repeater-converters are not requir-ed as with other bus systems. And unlike other bus systems, INTERBUShas active slaves.

The use of the ring structure offerstwo crucial advantages for the system.Firstly, the ring, unlike the linear struc-ture, offers the option of simultaneoustransmission and reception of data(full-duplex). On the other hand, anessential improvement in self-diagno-stics of the system can be achieved.In the case of linear bus systems with“multi-drop coupling” of the users, alldevices are connected passively to thebus (multi-drop = parallel coupling ofthe users to the bus, i.e. all users areconnected in parallel using the samephysical bus line). However, the passi-vity of the user is restricted only totrouble-free operation or to an inter-ruption in the bus interface of the user.However, if a fault in the bus interfaceof a user causes a short-circuit of thebus line or if the line is shorted at adifferent point outside of the user,communication is then not possible insuch a system. In this case of a fault, it is not possible to determine the faultpoint using automatic diagnostic func-tions of the network in linear systems.

By contrast, the principle of a ring sy-stem with active user coupling offerssegmentation of the communicationnetwork into electrically independentsections. In the case of an active faultof a user and a short-circuit or inter-ruption in the bus line, communicationfails only as of the fault point. It is pos-sible to localize the fault location vianetwork management functions in thebus master in order to allow targetedfault handling. The same applies in thecase of sporadic transmission disturb-ances, such as those triggered byelectromagnetic interference sourcesor faulty cabling. Telegrams are destroyed on a random basis as the result of this in the linear system.

The option of forming local sub-ringsystems in the INTERBUS networkalso allows non-retroactive couplingand decoupling of users. The connec-tive elements between the bus seg-ments allow connection and discon-nection of the sub-system, controlledby the central bus master.Manipulations on the sub-system arethus possible without retroactively affecting the rest of the system. Datais assigned to the individual users not, as is necessary in other systems,by assigning a bus address to the individual users, but via the physicallocation of the users in the ring sy-stem.

6.2 INTERBUS Loop

Sensors and actuators can also be integrated directly in the field via the INTERBUS Loop. It is possible to branch directly to the INTERBUSLoop via a “local bus branch”. Dataand power are transmitted on a com-mon two-wire line. The topology is agenuine ring structure, both physicallyand logically. The basic data is as follows:

■ Non-shielded two-wire line for data and power (2 x 1.5 mm2)

■ Maximum 32 users ■ Maximum 10 m between 2 users ■ Maximum 100 m overall■ No special power supply module

required.

6.3. Advantages of INTERBUS

■ INTERBUS allows very fast trans-mission of user data (in one buscycle time) with a low (physical)transmission speed (512 kB or 2MB) owing to the topology and the high protocol efficiency.

■ Good bus and slave diagnostic options

■ No dependence between linelength and cycle time

■ Large extent possible.

47

The AS-Interface (Actuator-Sensor Inter-face) is a serial transmission system foruse at the bottom-most field level of theautomation hierarchy. The AS-Interfacewas primarily designed as an economicalsystem for controlling binary actuatorsand sensors, but it is also possible, usingexpansions, to connect analog field units.AS-i can thus be turned into a sub-sy-stem or “feeder bus” for any higher-level field bus system. This structure isshown here. Gateways or couplers areavailable for all important field buses.

7.1. Mode of operation

The AS-Interface is a master-slave sy-stem with cyclic polling which usesone master per network that cyclicallycalls up all users of the periphery (theslaves) with their address. The pollingprocedure is strictly deterministic.AS-i telegrams are short, simplystructured and have a fixed length.Four usable data bits are exchangedbetween master and each slave ineach cycle. Longer information (suchas analog data or programming data)is transmitted automatically, distribu-ted over several cycles. The cycletime of AS-Interface, at full capacity of a system with 31 (Version 2.0) or62 (Version 2.1) slaves, is approx. 5or 10 ms. Depending on the powersupply module (30 V), it is possible to transmit up to 8 Amps on the busline. In addition, a (black, profiled) auxiliary power line can be used.

7.2. Topology

The topology of an AS-Interface net-work can be selected as required, thusmaking project planning very easy. Itcan be matched entirely to local re-quirements or can also be star-shaped,radial or linear, contain stubs or branchlike a tree. Line terminating resistorsare not required. The only boundarycondition that needs to be compliedwith is the restriction to a total lengthof 100 m. This must include all linelengths, including the lengths of stubs.It is possible to use up to two repea-ters wherever larger distances need tobe spanned. Virtually all cable types –non-shielded, non-twisted withoutspecial requirements – can be usedwhen networking

with AS-Interface. Therefore, no spe-cial bus cables are required. However,it is advantageous to use the yellow

AS-Interface cable since it featuressimple contacting and simple con-nection systems. This cable is a cod-ed ribbon cable which is thus pro-tected against reverse polarity andcan be used for connection to slavesor passive modules at any point witha simple piercing system (see Figure34). This cable is self-healing, i.e.protection type IP 67 applies againafter the connection modules are removed.

7.3. Transmission reliabilityand interference im-munity

Each AS-Interface telegram is moni-tored in the receiver with respect tothe parity bit, start bit, stop bit, Man-chester, timeout and pause time vio-lation error. In addition, transgressionof the telegram length is detected.

This ensures extremely high reliabilityof detection of single and multiple errors, whereby the effective hammingdistance is 5. The hamming distanceis used as a measure of the transmis-sion reliability in digital communica-tion systems and its numerical value

48

Ribbon cable protected against reverse polarity

Penetration domes

AS-Interface electromechanics

AS-Interface level:

Simple sensors and actuators

Slave Slave Slave Slave Slave Slave Slave

11 Machine-oriented control level: SPS, PC, IPC, etc.

Master

Field bus level:CANOpen DeviceNet FIP-I/O INTERBUS PROFIBUS DP

7. AS- In ter face

Figure 34: System structure

Figure 35

indicates how many errors may occurwithin a telegram without impairingthe detection reliability. If an error isdetected, an errored telegram is re-peated immediately. A telegram retrytakes 150 µs. This is already includedin the cycle time of 5 ms (2.0)/10 ms(2.1).

Due to a specific modulation methodcalled alternating pulse modulation,AS-Interface can be deployed in envi-ronments with high electrostatic/elec-tromagnetic interference (e.g. in thevicinity of welding systems or frequen-cy converters), despite the use ofnon-shielded bus cables.

7.4. Safety at Work

With its Safety at Work function, AS-Interface offers the option of transmit-ting standard data and safety-relateddata on the same cable. This enables,for example, emergency-stop cablingof a machine or system to be imple-mented via AS-i. This reduces installa-tion effort and expense.

49

7.5. Basic data of AS-Interface

The performance of AS-Interface hasbeen expanded within the scope oftechnical further development, prima-rily in terms of the maximum numberof users. These modifications wereimplemented in AS-Interface Specifi-cation 2.1. Field units in accordancewith this specification have been avail-able since early 2001.

Table 4: Basic data of AS-InterfaceVersion 2.0 (previous) Version 2.1

Number of slaves Maximum 31 Maximum 62Number of I/Os 124 I + 124 O 248 I + 186 OSignals Data and power supply up to 8 A Data and power supply up to 8 A

(dependent on power supply module) (dependent on power supply module) Medium Non-shielded, non-twisted cable Non-shielded, non-twisted cable

2 x 1.5 mm2 2 x 1.5 mm2

Max. cycle time 5 ms 10 msAnalog value transmission Via function block Integrated in masterNumber of analog values 16 bytes for binary 124 analog values

and analog values Access procedures Master/Slave Master/SlaveCable length 100 m, expansion via 100 m, expansion via

repeater to max. 300 m repeater to max. 300 m

2 Star

Control

Master

Linear

Control

Master

Tree

Control

Master

Figure 36: Possible AS-Interface topologies

HART (Highway Addressable RemoteTransducer) = protocol for bus-ad-dressed field units. It is not a fieldbus, but rather a variant of digital fieldcommunication that includes manyfunctionalities of field buses.

In the case of HART communication,field units are connected convention-ally via 4 ... 20 mA current loops(standard signal) or to controllers andopen-loop control systems with sucha standard signal output. Set-pointvalues (e.g. for digital positioners) oractual values (of transducers) aretransmitted via the standard signal.

In addition to signal transmission, withtwo-wire systems, these current sig-nals also power the field units. A digital signal (2200 Hz = 0, 1200Hz = 1) is modulated onto this analogsignal using the FSK method (Fre-quency Shift Keying). This also allowsmeasurement data, positioning dataand device data to be transmitted without influencing the analog signal.The response time per field unit is ap-prox. 500 ms. In addition, the HARTprotocol allows extensive integrationof the field units in engineering toolsand process control systems. HARTintrinsically safe isolators also permitusage in the explosion-hazard area.

The standard topology is a point-to-point connection with the analog sig-nal retained. HART topology may also be designedin multi-drop mode. This allows up to 15 users, as with a field bus, to beconnected to one common pair of wires. However, in multi-drop mode,the 4 ... 20 mA signal cannot be used – it merely makes available the basic 4mA current powering the devices. Theset-point values and actual values aretransmitted digitally. The long cycle times (up to several seconds depen-ding on number of users) do, howe-ver, greatly restrict the practical bene-fits of this variant.

50

Field unit

Time

Figure 37: Analog standard signal(4 ... 20 mA) with modulated-on digital signal

Figure 38: HART topologies, point-to-point connection

Process control system

Multiplexer

Barrier

Hand-held terminal

Optional:

8. HART

8.1. Cabling

The following cables are suitable forHART communication:■ Non-shielded two-wire lines for

short links■ Singly shielded, twisted pairs of

wires (0.2 mm2) up to 1500 m■ Singly shielded, twisted pairs of

wires (0.5 mm2) up to 3000 m.

8.2. HART commands

HART communication consists ofthree different classes of command: ■ Universal commands: these com-

mands are supported by all HARTfield units (e.g. measured value, value of the current output, measu-ring range limits)

■ Common practice commands: these commands cover functionswhich are supported by many, butnot all field units. Together, theyform a library for the functions occurring in most field units.

■ Device specific commands: thesecommands contain functions thatare restricted to one device model,e.g. commissioning and deviceconfiguration.

51

Figure 39: HART topologies, multi-drop mode

Process control system

I/O

Hand-held terminal

Field units

9. Communicat ions-enabled f ie ld uni tsf rom Bürker t

52

Type Designation PROFIBUS AS-i INTERBUS DeviceNet CANopen FOUNDATION HART Others

DP PA Fieldbus

1066 Control head for process valves ● ●

8630 TopControl Continuous ● ●

8631 TopControl On/Off ● ●

8633 Mini-Top On/Off ●

8635 Positioner SideControl ● ●

Control units for pneumatically operated process valves

Type Designation PROFIBUS AS-i INTERBUS DeviceNet CANopen FOUNDATION HART Others

DP PA Fieldbus

8642 I/O-Box ● ●

8643 Power-I/O-Box ● i.V. ●

Valve couplers

Type Designation PROFIBUS AS-i INTERBUS DeviceNet CANopen FOUNDATION HART Others

DP PA Fieldbus

8640 Valve block with field bus interface ● ● ● ● ● ●

8644 AirLINE ● ● ● ● ●(valve block with field bus interface + remote I/O)

Valve islands

53

Type Designation PROFIBUS AS-i INTERBUS DeviceNet CANopen FOUNDATION HART Others

DP PA Fieldbus

8025 Flow transmitter ●

8032 Flow switch ●

8035 Flow transmitter ●

8075 Flow transmitter ●

8181 Level switch ●

8311 Pressure switch ● ●

8326 Pressure transmitter ●

8400 Temperature switch ● ●

Sensors

Type Designation PROFIBUS AS-i INTERBUS DeviceNet CANopen FOUNDATION HART Others

DP PA Fieldbus

1150 Industrial controllers ●

2511 Appliance plug socket ●

8623 Cable plug flow controller ● ●

8624 Cable plug pressure controller ● ●

8625 Cable plug temperature controller ● ●

Other field bus devices

Type Designation PROFIBUS AS-i INTERBUS DeviceNet CANopen FOUNDATION HART Others

DP PA Fieldbus

8025/ MFC/MFM RS-232/

8700 RS-485

8712/ MFC/MFM ● ● RS-232/

8702 RS-485

8716/ MFC/MFM ● ● RS-232/

8706 RS-485

8626 MFC/MFM ● ● RS-232/

8006 RS-485

Mass Flow Controllers/Meters (MFC/MFM)

10. L is t o f keywords

54

A

Acyclic communication Page 16Arbitration Page 43AS-i Page 10Asset management Page 12Automation levels

Page 8

C

CAL Page 44CAN Page 11CANopen Page 42CIP Page 36Communication Page 35Component model Page 33CSMA/CD Page 11Cyclic communication

Page 18

D

Deterministic Page 48Device Description (DD) Page 13Device integration Page 25DeviceNet Page 13DP V0, V1, V2 Page 17DTM Page 18

55

E

EDD Page 18Electronic data sheet (GSD) Page 18Ethernet Page 11Ethernet/IP Page 32Explosion-hazard area Page 19

F

FDE Page 20FDT Page 18Field bus Page 8Field level Page 8FISCO Page 19Flexible Function Block Page 41FOUNDATION Fieldbus (FF) Page 13Function block model Page 29

G

GSD Page 18

56

H

H1 Page 26Hamming distance Page 48HART Page 13HSE Page 26

I

IAONA Page 32IDA Page 32Industry requirements Page 14INTERBUS Loop Page 47INTERBUS Page 46ISO/OSI model Page 10

L

LAS Page 27Linear structure Page 9

57

M

Master Page 16Master-slave procedure Page 16MBP Page 17Modular system Page 17Multi-drop Page 47Multiplexer

Page 50

N

Network topologyPage 9

O

ODVA Page 36Optical waveguide Page 17OSI model Page 10

P

PA Page 17PDM Page 24Polling procedure Page 48Powerlink Page 32Process industry Page 15Production industry Page 14PROFIBUS Page 11Profiles Page 17PROFInet I/O Page 32PROFInet Page 32Publisher Page 27

58

R

Real time Page 11Ring structure Page 9RS-485 Page 17RS-485-IS Page 20RS-422 Page 46

S

Star structure Page 9Stubs Page 17Subscriber Page 27Switching Page 31

T

Token-passing procedure Page 16Topology Page 9Tree structure Page 9

59

All technical details were valid at thetime of going to print. Since we arecontinuously developing our products,we reserve the right to make technicalalterations. Unfortunately, we alsocannot fully exclude possible errors.Please understand that no legal claimscan be made bared upon either thedetails given or the illustrations anddescriptions provided.

Texts, photographs, technical draw-ings and any other form of presenta-tions made in this publication are pro-tected by copyright and property ofBürkert Fluid Control Systems GmbH& Co. KG.

Any further use in print or electronicmedia requires the express approvalof Bürkert GmbH & Co. KG. Any formof duplication, translation, processing,recording on microfilm or saving inelectronic systems is prohibited with-out the express approval of Bürkert GmbH & Co. KG.

Bürkert GmbH & Co. KGFluid Control Systems Christian-Bürkert-Straße 13-17D-74653 Ingelfingen

60/59

Burkert Service and Distribution Network

AustraliaBurkert Fluid Control SystemsNo. 2 Welder Road,Seven Hills, NSW 2147Tel. +61 1300 888 868Fax +61 1300 888 076

AustriaBurkert-Contromatic Ges.m.b.H.Diefenbachgasse 1-3 1150 Wien (Vienna)Tel. +43 (0) 1 894 13 33Fax +43 (0) 1 894 13 00

BelgiumBurkert-Contromatic SABijkhoevelaan 32110 WijnegemTel. +32 (0) 3 325 89 00Fax +32 (0) 3 325 61 61

BrazilBurkert-Contromatic Brasil Ltda.Rua Américo Brasiliense no. 2171 cj 100704715-005 São Paulo - SPTel. +55 (0) 11 5182 0011Fax +55 (0) 11 5182 8899

CanadaBurkert Contromatic Inc.760 Pacific Road, Unit 3Oakville (Ontario) L6L 6M5Tel. +1 905 847-55 66Fax +1 905 847-90 06

ChinaBurkert Contromatic (Suzhou) Co., Ltd.9-2 Zhu Yuan Road,Suzhou New DistrictJiangsu, China. 215011Tel. +86 512 6808 19 16Fax +86 512 6824 51 06

Czech RepublicBurkert-Contromatic Ges.m.b.H.Branch-Office AustriaKrenova 35602 00 BrnoTel. +42 05 43 25 25 05Fax +42 05 43 25 25 06

DenmarkBurkert-Contromatic A/SHørkær 242730 HerlevTel. +45 44 50 75 00Fax +45 44 50 75 75

FinlandBurkert OyAtomitie 500370 HelsinkiTel. +358 (0) 9 549 70 600Fax +358 (0) 9 503 12 75

FranceBurkert Contromatic FranceRue du GiessenBP 2167220 Triembach au ValTel. +33 (0) 3 88 58 91 11Fax +33 (0) 3 88 57 20 08

GermanyBürkert GmbH & Co. KGChristian-Bürkert-Straße 13-17D-74653 IngelfingenTel. +49 (0) 7940 10 111Fax +49 (0) 7940 10 448

Hong KongBurkert-Contromatic (China/HK) Ltd.Unit 708, Prosperity Centre77-81, Container Port RoadKwai Chung N.T., Hong KongTel. +85 2 2480 1202Fax +85 2 2418 1945

ItalyBurkert Contromatic Italiana S.p.A.Centro Direzionale „Colombirolo“Via Roma 7420060 Cassina De´Pecchi (Mi)Tel. +39 02 95 90 71Fax +39 02 95 90 72 51

JapanBurkert-Contromatic Ltd.1-8-5 Asagaya MinamiSuginami-kuTokyo 166-0004Tel. +81 (0) 3 5305 3610Fax +81 (0) 3 5305 3611

KoreaBurkert Contromatic Korea Co., Ltd.287-2, Doksan 4 DongKumcheon-kuSeoul 153-811Tel. +82 (0) 3 3462 5592Fax +82 (0) 3 3462 5594

NetherlandsBurkert-Contromatic BVComputerweg 93542 DP UtrechtTel. +31 (0) 346 58 10 10Fax +31 (0) 346 56 37 17

New ZealandBurkert Contromatic Ltd.2A, Unit L, Edinburgh StPenrose, AucklandTel. +64 (0) 9 622 2840Fax +64 (0) 9 622 2847

NorwayBurkert Contromatic A/SHvamstubben 172013 SkjettenTel. +47 63 84 44 10Fax +47 63 84 44 55

PhilippinesBurkert Contromatic Philippines, Inc.8467 West Service RoadSouth Superhighway, SunvalleyParanaque City, Metro ManillaTel. +63 2 776 43 84Fax +63 2 776 43 82

PolandBurkert-Contromatic Ges.m.b.H.Branch-Office AustriaBernardynska street 14 a02-904 WarszawaTel. +48 22 840 60 10Fax +48 22 840 60 11

PortugalBurkert ContromaticTel. +351 21 382 80 00Fax +351 21 387 36 79

SingaporeBurkert Contromatic Singapore Pte. Ltd.51 Ubi Avenue 1, #03-14Paya Ubi Industrial ParkTel. +65 6844 2233Fax +65 6844 3532

South AfricaBurkert Contromatic (Pty) Ltd.233 Albert Amon RoadMillenium Business ParkMeadowaleEdenvaleTel. +27 (0) 11 397 2900Fax +27 (0) 11 397 4428

SpainBurkert Contromatic S.A.Avda. Barcelona, 4008970 Sant Joan Despi (Barcelona)Tel. +34 93 477 79 80Fax +34 93 477 79 81

SwedenBurkert-Contromatic ABSkeppsbron 13 B211 20 MalmöTel. +46 (0) 40 664 51 00Fax +46 (0) 40 664 51 01

SwitzerlandBurkert-Contromatic AG SchweizBösch 716331 HünenbergTel. +41 (0) 41 785 66 66Fax +41 (0) 41 785 66 33

TaiwanBurkert Contromatic Taiwan Ltd.3F, No. 475, Kuang-Fu South RoadTaipei, TaiwanTel. +886 (0) 2 2758 3199Fax +886 (0) 2 2758 2499

TurkeyBurkert Contromatic AkiskanKontrol Sistemleri Ticaret A.S.1203/8 Sok. No 2-EYenisehir, IzmirTel. +90 (0) 232 459 53 95Fax +90 (0) 232 459 76 94

United KingdomBurkert Fluid Control SystemsBrimscombe Port Business ParkBrimscombe, Stroud, Glos., GL5 2QFTel. +44 (0) 1453 73 13 53Fax +44 (0) 1453 73 13 43

USABurkert Contromatic USA2602 McGaw AvenueIrvine, CA 92614U.S.A.Tel. +1 949 223 3100Fax +1 949 223 3198

Systemkatalog 6

Magnetventile I Prozess- und Regelventile I Pneumatik

Sensoren I MicroFluidics I MFC und Proportionalventile

The smart choice of Fluid Control Systems

Systemkatalog 1

Magnetventile I Prozess- und Regelventile I Pneumatik

Sensoren I MicroFluidics I MFC und Proportionalventile

The smart choice of Fluid Control Systems

Systemkatalog 2

Magnetventile I Prozess- und Regelventile I Pneumatik

Sensoren I MicroFluidics I MFC und Proportionalventile

The smart choice of Fluid Control Systems

Systemkatalog 5

Magnetventile I Prozess- und Regelventile I Pneumatik

Sensoren I MicroFluidics I MFC und Proportionalventile

The smart choice of Fluid Control Systems

Service brochure

A systematic overview of the

range of products and services

offered by Bürkert. A network of

comprehensive solutions inte-

grating coordinated services.

Competence brochures

Essential information for the person

planning control loops and field

bus systems and who wants to

ensure basic knowledge of the

structure and selection of system

components.

Application brochures

Example applications for deriving

the appropriate system solution,

supplemented by information on

product advantages, user advan-

tages and the range of products

specifically available.

System catalogs

Background knowledge on product

technology, including an up-to-date

overview of the current offers.

Rounded out with information to

help you make your decision on

the best application option.

Technical data sheets

Detailed technical information

for checking specific suitability.

In addition, all the data needed

for direct ordering.

Information paves the path to the appropriate system solution. We provide five

different levels for accessing information, products and services, so that you can

easily find out everything you need to know to make the right choice.

8942

36/0

9/03

/Bur

eau

Sch

irle

Bürkert Fluid Control Systems, Christian-Bürkert-Straße 13–17, 74653 Ingelfingen, Germany

Tel.+49 (0) 79 40/10-0,Fax+49 (0) 79 40/10-204, info@de.buerkert.com, www.buerkert.com