UNIT 3

HART AND FIELDBUS

Field networks are not the only solution when plant operators want to use the advantages
of smart field devices. The HART protocol provides many possibilities even for installations that
are equipped with the conventional 4 to 20mA technique.
HART devices communicate their data over the transmission lines of the 4 to20mA
system. This enables the field devices to be parameterized and started up in a flexible manner
or to read, measured and stored data (records).All these tasks require field devices based on
microprocessor technology. These devices are frequently called smart devices. Introduced in
1989, this protocol has proven successful in many industrial applications and enables
bidirectional communication even in hazardous environments.
HART allows the use of up to two masters: the engineering console in the control room
and a second device for operation on site, e.g. a PC laptop or a handheld terminal. . A standard
hand-held terminal called the HART communicator is available to make field operations as
uniform as possible. The current version of the HART Protocol is revisionThe "7" denotes the
major revision level and the "2" denotes the minor revision level.
The HART Protocol communicates at 1200 bps without interrupting the 4-20mA signal
and allows a host application (master) to get two or more digital updates per second from a smart
field device. As the digital FSK signal is phase continuous, there is no interference with the 4-
20mA signal.

EVOLUTION OF SIGNAL STANDARD

“HART” is an acronym for Highway Addressable Remote Transducer. The HART
Protocol makes use of the Bell 202 Frequency Shift Keying (FSK) standard to superimpose
digital communication signals at a low level on top of the 4-20mA. ‘4-20mA’ is a tried, tested
and widely used standards, because only a limited amount of information is sent by a 4-20mA
signal. Smart field devices using the HART protocol enhances operations because digital data is
transmitted along with the 4-20mA signal - without interfering it.
This enables two-way field communication to take place and makes it possible for
additional information beyond just the normal process variable to be communicated to/from a
smart field instrument. The digital signal is made up from two frequencies - 1200 Hz and 2200
Hz, representing bits 1 and 0 respectively. Sine waves of these frequencies are superimposed on
the DC analog signal cables to give simultaneous analogue and digital communications. Because
the average value of the FSK signal is always zero, the 4-20mA signal is not affected.This
produces simultaneous communication with a response time of approximately 500mS for each
field Device, without interrupting any analog signal transmission that might be taking place.

HART COMMUNICATION PROTOCOL

HART technology is a master/slave protocol, which means that a smart field (slave)
device only speaks when spoken to by a master.Master devices include handheld terminals as
well as PC-based work places, e.g. in the control room. HART slave devices, on the other hand,
include sensors, transmitters and various actuators.
The HART Protocol can be used in various modes such as point-to-point or multidrop for
communicating information to/from smart field instruments and central control or monitoring
systems.
 HART Communication occurs between two HART-enabled devices, typically a smart
field device and a control or monitoring system. Communication occurs using standard
instrumentation grade wire and using standard wiring and termination practices.
The HART Protocol provides two simultaneous communication channels: the 4-
20mA analog signal and a digital signal. The 4-20mA signal communicate the primary measured
value (in the case of a field instrument) using the 4- 20mA current loop - the fastest and most
reliable industry standard. Additional device information is communicated using a digital signal
that is superimposed on the analog signal.

The HART data is superimposed on the 4 to 20mA signal via a FSK modem.
This enables the devices to communicate digitally using the HART protocol, while analog signal
transmission takes place at the same time. Field devices and compact handheld terminals have an
integrated FSK modem, whereas PC stations have a serial interface to connect the modem
externally.

u
' Time (sec)

HART Command/Response
To encode the bits, the FSK method (Frequency Shift Keying) based on thr Bell 202
communication standard is used. The two digital values ‘0’ and ' are assigned to the following
frequencies.
 ■ Logical ‘O’: 2200Hz
■ Logical ‘1’: 1200Hz
Sine waves of these two frequencies are superimposed on the direct currer (dc) analog
signal cables to provide simultaneous analog and digiia communications. Because the average
value of the FSK signal is always zerc the 4-20mA analog signal is not affected.
The digital communication signal has a response time of approximately 2-3 data updates
per second without interrupting the analog signal. A minimum loop impedance of 230 W is
required for communication. Each individual byte of the layer-2 telegram is transmitted as
eleven-bit UART character at a dan rate of 1200 bits/s.
The HART specification defines that master devices send voltage signals while the field
devices (slaves) convey their messages using load-independer/ currents. The current signals
are converted to voltage signals at the interna resistance of the receiver (at its load). To ensure
a reliable signal reception, the HART protocol specifies the total load of the current loop
including the cab!: resistance to be between minimum 230 ohms and maximum 1100 ohms.
Usually, the upper limit is not defined by this specification, but results from the limited power
output of the power supply unit

HART NETWORKS
HART devices can operate in one of two network configurations,
POINT-TO-POINT MODE
The conventional 4-20mA signal continues to be used for analog transmission while
measurement, adjustment and equipment data is transferred digitally.
The HART master device is connected to exactly one HART field device. This :
connection variant requires that the device address of the field device be always set to zero since
the operating program uses this address to establish I communication.
The analog signal remains unaffected and can be used for control in the normal way.
HART data gives access to maintenance, diagnostic and other operational data.

Point to Point Mode

MULTIPLEXER
The use of a multiplexer system, which enables a large number of HART devices to be
connected in a network. The user selects a particular current loop for communication via the
operating program.
 Multiplexer Mode

As long as the communication takes place, the multiplexer connects the current loop to the
host. Due to the cascaded multiplexer structure, the host can communicate with many (> 1000)
devices, all with the address zero.

MULTI DROP MODE

This mode requires only a single pair of wires and, if applicable, safety barriers and an
auxiliary power supply for up to 15 field devices. The host distinguishes the field devices by
their preset addresses which range from 1 to 15. In multi drop operation, the devices exchange
their data and measured values only via the HART protocol.
The analog current signal serves just to energize the two-wire device: providing a direct
current of 4 mA. Control valves cannot be used : conjunction with multi-drop mode. Thecontrol
signals for valves are therefor: always transmitted as 4 to 20 mA standardized current signals.
Multi-drop connection is particularly useful for supervising installations the: are widely spaced,
such as pipelines, feeding stations and tank farms.

Multi drop mode

HART instruments can be used in either mode. In point-to-point operations, the field
device has address 0, setting the current output to 4-20 mA. In multi-drop mode, all device
addresses are greater than zero and each device sets its output current to 4 mA. For this mode of
operation, controllers and indicators must be equipped with a HART modem.
HART COMMANDS
The HART command set provides uniform and consistent communication for all field
devices. Universal commands: All devices using the HART protocol must recognize and support
the universal commands. It provides access to information useful in normal operations.
Common practice commands: common practice commands provide functions implemented by
many, but not necessarily all, HART communication devices. Device-specific commands:
Device-specific commands represent functions that are unique to each field device. These
commands access setup and calibration information, as well as information about the
construction of the device. Information on device-specific commands is available from the
device manufactures.

TO ADDRESS THE DEVICES:

A special, long form of addressing is used. Each HART device has a 38-bit address that
consists of the manufacturer ID code, device type code, and device-unique identifier. A unique
address is encoded in each device at the time of manufacture.
*A HART master must know the address of a field device in order to communicate successfully
with it.During the configuration phase, the bus address and the tag number of each device are set
via the point-to-point line. When using the HART command 0, it enables a master to learn the
address of each slave device without user interaction. When using the HART command 11, the
host can also address the device via its tag.
*In this way, the system configuration can be read and checked during the start-up
phase.To be able to connect a HART communication system with other communication systems,
gateways are used. They convert the respective protocols of the networks to be coupled. Even
without complex protocol conversions, HART enables communication over long distances.
*HART signals can be transmitted over telephone lines using HART/CCITT converters. Field
devices directly connected to dedicated lines owned by the company can thus communicate with
the centralized host located many miles away.

TWO-WIRE TECHNIQUE AND LOAD IMPEDANCE

HART signals are imposed on the conventional analog current signal. Whether the
devices are designed in four-wire technique including an additional power supply or in two-wire
technique, HART communication can be used for both cases. However, it is important to note
that the maximum permissible load of a HART device is fixed.
The analog current signal is transmitted via an A/D converter to the microprocessor
which is responsible for the application, e.g. for position control.

Two wire technique

The higher the power consumption of a two-wire device, the higher its load. The additional functions of
a HART-communicating device increase its power consumption and hence the load.
 The FSK modem feeds the received HART signals to the microprocessor which
computes the communication data.The FSK modem superimposes the HART signals to be sent
on the analog current signal of the 4 to 20mA line.
HART COMMUNICATION LAYERS:
The HART protocol utilizes the OSI reference model. As is the case for most of the
communication systems on the field level, the HART protocol implements only the layers
1, 2 and 7 of the OSI model.
OSI TCP/IP HART

Wired (FSKUPSKJRS485) Wireless 2.4 GHz

HART Communication Layers
The layers 3 to 6 remain empty, since their services are either not required or provided by
the application layer 7.
Physical Layer
Data transmission between the masters and the field devices is physically realized by
superimposing an encoded digital signal on the 4 to 20 mA current loop.
Since the coding has no mean values, an analog signal transmission taking place at the same
time is not affected.
This enables the HART protocol to include the existing simplex channel transmitting the
current signal (analog control device field device) and an additional half-duplex channel for
communication in both directions.
The bit transmission layer defines an asynchronous half-duplex interface which operates on
the analog current signal line.
Data Link Layer
The HART protocol operates according to the master-slave method. An; communication
activity is initiated by the master, which is either a contrc station or an operating device. HART
accepts two masters, the primary master Usually the control system and the secondary master a
PC laptop or Hand-he!: terminal used in the field.

Master/Slave method
HART field devices, the slaves never send without being requested to do so. They
respond only when they have received a command message from the master. Once a transaction,
i.e. a data exchange between the control station and the field device, is complete, the master will
pause for a fixed time period before sending another command, allowing the other master to
break in. The two masters observe a fixed time frame when taking turns communicating with the
slave devices.

Application Layer
The Application Layer defines the commands, responses, data types and status reporting
supported by the Protocol.
. The HART masters are simply connected in parallel to the field devices, so the devices
can be connected and disconnected during operation because the current loop need not be
interrupted.
. HART wiring in the field usually consists of twisted pair cables. If very thin and/or long
cables are used, the cable resistance increases and, hence, the total load. As a result, the signal
attenuation and distortion increases while the critical frequency of the transmission network
decreases.
If interference signals are a problem, long lines must be shielded. The signal loop and the
cable shield should be grounded at one common point only. According to the specification, the
following configurations work reliably:
For short distances, simple unshielded 0.2 mm2 two-wire lines are sufficient. For
distances of up to 1,500 m, individually twisted 0.2 mm2 wire pairs with a common shield over
the cable should be used. For distances of up to 3,000 m, individually twisted 0.5 mm2 two-wire
lines shielded in pairs are required. Most of the wiring in the field meets these requirements and
can therefore be used for digital communication.
. An essential benefit is that HART integrates the existing wires. So the HART
specification does not prescribe the use of a specific type of plug connector. Since the polarity
has no influence on the frequency evaluation, HART signals are usually connected via simple
clamp terminals.

HART-COMPATIBLE FEATURES
. HART communication between two or more devices can function properly only when
all communication participants are able to interpret the HART sine- wave signals correctly. To
ensure this, not only the transmission lines must fulfill certain requirements also the devices in
the current loop which are not part of the HART communication can impede or even prevent the
transmission of the data.
The reason is that the inputs and outputs of these devices are specified only for the 4 to
20mA technology. Since the input and output resistances change with the signal frequency, such
devices are likely to short-circuit the higher frequency HART signals (1200 to 2200 Hz).
Inputs and outputs with an internal resistance that falls below the FSK frequency range
short-circuit the HART signals. To prevent this, the internal resistance must be increased using
an additional circuit. The RC low pass performs this function.

COMMUNICATION MODES
The HART protocol provides standard and broadcast commands:
Standard Command : Master/Slave data exchange
Broadcast Command : HART Command received by all devices
The communication mode is used for the normal data exchange. When connection is
established, the HART command 11 can be used to send a broadcast message to all devices to
check the system configuration. Some HART devices support the optional burst communication
mode

Master-Slave Mode
HART is a master-slave communication protocol, which means that during normal
operation, each slave communication is initiated by a master communication device. Two
masters can connect to each HART loop. The primary master is generally a DCS, PLC, or PC. a
The secondary master can be a handheld terminal or another PC. Slave devices include
transmitters, actuators, and controllers that respond to commands from the primary or secondary
master.

Burst Mode
Some HART devices support the optional burst communication mode. Burst mode
enables faster communication (3-4 data updates per second). In burst mode, the master instructs
the slave device to continuously broadcast a standard HART reply message. The master receives
the message at the higher rate until it instructs the slave to stop bursting.

Frame Format
. The simplest form of a transaction is a master telegram which is directly followed by a
response or acknowledgement telegram from the slave. A single field device cyclically sends
message telegrams with short 75-ms breaks, which can alternately be read by the primary as well
as the secondary master. While usually only two transactions per second are possible, the field
device can send up to four telegrams.
Telegram Structure
The structure of a HART telegram is shown in Fig. Each individual byte is send as 11 -
bit UART character equipped with a start, parity and a stop bit. The HART protocol provides
two telegram formats which use different forms of addressing. In addition to the short frame
slave address format containing four bits, a long frame address format has been introduced as an
alternative.
. This allows more participants to be integrated, while achieving more safety in case of
incorrect addressing during transmission failures.

The elements of the HART telegram perform the following tasks:

The preamble consisting of three or more hexadecimal FF characters synchronizes the
signals of the participants.
The start byte indicates which participant is sending (master, slave, and slave in burst
mode) and whether the short frame or the long frame format is used.
The address field of the short frame format contains one byte with one bit
serving to distinguish the two masters and one bit to indicate burst-mode telegrams. For the
addressing of the field devices, 4 bits are used (addresses 0 to 15).
The address field of the long frame format contains five bytes: hence, the field
device is identified using 38 bits.
The command byte encodes the master commands of the three categories,
Universal, Common-practice and Device-specific commands. The significance of these
commands depends on the definitions in the application layer 7.
The byte count character indicates the message length, which is necessary since
the number of data bytes per telegram can vary from 0 to 25. This is the only way to enable the
recipient to clearly identify the telegram and the checksum. The number of bytes depends on the
sum of the status and the data bytes.
The two status bytes are included only in reply messages from slaves and contain
bit-coded information. They indicate whether the received message was correct and the
operational state of the field device. When the field device operates properly, both status bytes
are set to logical zero

The data can be transmitted as unsigned integers, floating-point numbers or

ASCII-coded character strings. The data format to be used is determined by the command byte,
however, not all commands or responses contain data.
The checksum byte contains the longitudinal parity of all the bytes of a telegram.

Communication Routines
* The communication routines of HART master devices and operating programs are based on
HART commands which are defined in the application layer of the HART protocol. Pre-defined
commands enable the master device to give instructions to a field device or send messages/data.
So set points, actual values and parameters can be transmitted and various services for start-up
and diagnostics performed.
* The field devices immediately respond by sending an acknowledgement telegram which can
contain requested status reports and/or the data of the field device. The example in Fig shows
what the transmitted bytes mean in a transaction initiated using the command 33. This HART
command enables the master to read four transmitter variables of the field device and the
corresponding units of measurement with only one command.
*To enable a universal communication, the HART commands are classified according to their
function into commands for master devices and for field devices. In shorter messages, the ratio
between user data and control data becomes increasingly unfavorable so that it can take up to
128 ms to transmit one user data byte.
* An average of 500 ms is accounted for per transaction, i.e. for both a mastc and a slave
telegram, including additional maintenance and synchronization times. As a result,
approximately two HART transactions can be carried out per second.
These values show that the HART communication is not suitable retransmitting time-critical
data. HART can be used to determine the reference variable of a final control element in test and
start-up phases, but it is obvious! not suited to solve control tasks.
FEATURES OF THE HART PROTOCOL
The most important performance features of the HART protocol include:
proven in practice, simple design, easy to maintain and operatecompatible with conventional
analog instrumentationsimultaneous analog and digital communicationoption of point-to-point or
multi-drop operationflexible data access via up to two master devicessupports multivariable field
devicessufficient response time of approx. 500 msopen de-facto standard freely available to any
manufacturer or user

HART APPLICATIONS
The HART protocol is a powerful communication technology used to exploit the full potential
of digital field devices. Preserving the traditional 4-20mA signal, the HART protocol extends
system capabilities for two-way digital communication with smart field instruments.
The HART protocol offers the best solution for smart field device communication and has the
widest base of support of any field device protocol worldwide. The HART protocol provides a
unique communication solution that is backward compatible. This backward compatible ensures
that investment in existing cabling and current control strategies will remain secure well into the
future.
The various benefits are,
Improved plant operations
Operational flexibility
Instrumentation investment protection
Digital communication
IMPROVED PLANT OPERATIONS
The HART protocol improves plant performance and provides savings in:
Commissioning and installation
Plant operations and improved quality
Maintenance

HART-based field devices can be installed and commissioned in a fraction x the time
required for a traditional analog-only system. Operators who use HART digital communications
can easily identify a field device by its tag am verify that operational parameters are correct.
FIELDBUS
Field bus is the technological evolution to digital communication in instrumentation and
process control. It differs from any other communication protocol, because it is designed to
resolve process control applications instead of just transfer data in a digital mode.
Field bus is an all-digital, serial, two-way communication system, which interconnects “field”
equipment such as sensors, actuators and controllers. Field bus is a Local Area Network (LAN)
for instruments used in both process and manufacturing automation with built-incapability to
distribute the control application across the network.
. Field bus network requires three basic elements - the host or controller, the field instruments
or transmitters and the interface hardware. Field bus technology offers several advantages over
conventional (4 to20mA - analog) technology, such as power and communication on a single
pair of wires, more robust communication, more information from intelligent field devices, full
support of a distributed - multi-drop architecture, and interoperability.
It also supports all possible application areas including hazardous locations. Therefore, Field
buses represent an ideal technology for the process industry

GENERAL FIELDBUS ARCHITECTURE

Communication specifications are often explained with reference to the Open System
Interconnect (OSI) layered model. Fieldbus is specified according to the simplified OSI
model, consisting of three (3) layers: Physical Layer (PHL), Data Link Layer (DLL) and
Application Layer (APL).Fieldbus architectureLayers 2 to 7 are implemented mostly by software
and therefore are ofte: called the “communication stack.” Fieldbus Foundation specifies not only
the communication but also some user applications, which use fieldbui communication, though
the OSI model does not specify any user application. Figure 3.12 shows the architecture of
fieldbus.
Basic requirements of Field bus standard
The control strategy is distributed along the field devices. It is possible because, besides
having function blocks in their microprocessors, they have also ability to communicating fast and
reliably to each other through the bus.
* Devices can be networked and configured according to the user needs, being suitable from
small systems to whole plants. Field bus is changing the concept of process management as an
enabling technology and new tasks are made possible to automation professionals, such as new
configurations, online performance diagnostic and maintenance records and tools. Field bus is
the Smart solution for the process automation of today.
* Significant benefits are achieved in the control system life-cycle through the application of
field bus technology. Field bus -uses standard “Function Blocks” to implement the control
strategy. Function Blocks are standardized automation functions.Many control system functions
such as analog input (Al), analog output (AO) and Proportional/integral/Derivative (PID) control
may be performed by the field device through the use of Function Blocks.
*The consistent, block-oriented design of function blocks allows distribution of functions in
field devices from different manufacturers in an integrated and seamless manner. Distribution of
control into the field devices can reduce the amount of I/O and control equipment needed
including card files, cabinets, and power supplies.

Fieldbus multi-topology
The field bus allows many devices to be connected to a single wire pair. This results in less
wire, fewer intrinsic safety barriers, and fewer marshaling cabinets. In traditional automation
systems, the amount of information available to the user did not go farther than the control
variables. Field bus, the amount is much larger, due mainly to the facilities of the digital
communication.
Besides that, field bus has increased resolution and no distortion (no A/D or D/A
conversions), which gives more reliability to the control. All this added to the fact that the
control is held within the field devices results in better loop performance and less degradation.
The field bus allows multiple variables from each device to be brought into the control
system for archival, trend analysis, process optimization studies, and report generation. The high
resolution and distortion-free characteristics of digital communications enables improved control
capability, which can increase product yields.
The self-test and communication capabilities of microprocessor-based field devices help
reducing downtime and improving plant safety. Upon detection d abnormal conditions or the
need for preventive maintenance, plant operati: and maintenance personnel can be notified. This
allows corrective action to be| initiated quickly and safely

FIELD BUS TOPOLOGIES

Foundation Field bus allows for many different topologies. The me | commonly used are
bus topology or tree topology, or some mix of the two (2)

[] Device (node)
ConsWer all the segments to
TR = Tefminator calculate the maximum lengths
Fieldbus Topologies Fieldbus technology consists of three parts:
1 - The Physical Layer;
2 - The Communication “Stack”;
3 - The User Application.
The Open Systems Interconnect (OSI) layered communication model is used to model
these Components.
The Physical Layer is OSI layer 1. The Data Link Layer (DLL) is OSI
layer 2. The Field bus Message Specification (FMS) is OSI layer 7.
The Communication Stack is comprised of layers 2 and 7 in the OSI model.
The field bus does not use the OSI layers 3, 4, 5 and 6. The Field bus Access Sub layer
(FAS) maps the FMS onto the DLL.
The User Application is not defined by the OSI model. The Field bus Foundation has
specified a User Application model.
Each layer in the communication system is responsible for a portion of the message that is
transmitted on the field bus.
The numbers below show the approximate number of eight bit “octets” used for each layer
to transfer the USER data.
THE PHYSICAL LAYER
The Physical Layer is defined by approved standards from the International Electro
technical Commission (IEC) and the International Society of Measurement and Control (ISA).
The Physical Layer receives messages from the communication stack and converts the
messages into physical signals on the field bus transmission medium and vice-versa.

. Conversion tasks include adding and removing preambles, start delimiters, and end
delimiters Field bus signals are encoded using the well-known Manchester Biphase-L technique.
The signal is called “synchronous serial” because the clock information is embedded in the serial
data stream
Data is combined with the clock signal to create the field bus signal .The receiver of the fieldbus
signal interprets a positive transition in the middle of a bit time as a logical “O” and a negative
transition as a logical “1”.
The preamble is used by the receiver to synchronize its internal clock with the incoming field
bus signal.
Special N+ and N- codes are in the start delimiter and end delimiter. Note that the N+ and
N signals do not transition in the middle of a bit time.
The receiver uses the start delimiter to find the beginning of a fieldt_ : message. After it findsthe
start delimiter, the receiver accepts data until the end delimiter is received.
The transmitting device delivers + 10mA at 31.25 kbit/s into a 50 olrr equivalent load to create al
.0 volt peak-to-peak voltage modulated on top c the direct current (DC) supply voltage.
The DC supply voltage can range from 9 to 32 volts, however for I.S applications, the
allowed power supply voltage depends on the barrier ratini 31.25 kbit/s devices can be powered
directly from the field bus and can opera:; on wiring that was previously used for 4-20mA
devices.
The 31.25 kbit/s field bus also supports intrinsically safe (I.S.) field buses with bus powered
devices.
To accomplish this, an I.S. barrier is placed between the power supply in the safe area and the
I.S. device in the hazardous area. Field bus allows stubs or “spurs”
The length of the field bus is determined by the communication rate, cable type, wire size,
bus power option, and I.S. option.
High Speed Ethernet
A Linking Device is used to interconnect 31.25 kbit/s field buses and make them accessible
to a High Speed Ethernet (HSE) backbone running at lOOMbit/s or 1 Gbit/s.
The I/O Subsystem Interface allows other networks such as Device Net and Profibus to be
amped into standard Field bus function blocks.
The TO Subsystem Interface can be connected to the 31.25 Kbit/s field bus or HSE. Since all
of the 31.25 kbit/s Field bus messages are communicated on the HSE using standard Ethernet
protocols (e.g., TCP/IP, SNTP, SNMP, etc.), commercial off-the-shelf HSE equipment such as
Switches and Routers are used to create larger networks.

High Speed Ethernet

Of course all or part of the HSE network can be made redundant to achieve the level fault
tolerance needed by the application.
COMMUNICATION STACK OF FIELDBUS
The following sections will describe the operation of the layers in the Communication Stack.
Communication Stack I 9.2.1. Data Link Layer (DLL)

. Layer 2, the Data Link Layer (DLL), controls transmission of messages onto the field bus.
The DLL manages access to the field bus through a deterministic centralized bus scheduler
called the Link Active Scheduler (LAS).
^ The DLL is a subset of the emerging IEC/ISA DLL standard.
. Two types of devices are defined in the DLL specification:
Basic Device
Link Master

Data Link Layer ts. Link Master Devices are capable of becoming the Link Active Scheduler
(LAS). Basic devices do not have the capability to become the LAS.
The Link Active Scheduler (LAS) has a list of transmit times for all data buffers in all
devices that need to be cyclically transmitted. When it is time for a device to send a buffer, the
LAS issues a Compel Data (CD) message to the device.
Upon receipt of the CD, the device broadcasts or “publishes” the data in the buffer to all
devices on the field bus. Any device that is configured to receive the data is called a “subscriber”
Scheduled data transfers are typically used for the regular, cyclic transfer of control loop data
between devices on the field bus.
All of the devices on the field bus are given a chance to send “unscheduled” messages
between transmissions of scheduled messages. The LAS grants permission to a device to use the
field bus by issuing a pass token (PT) message to the device.
When the device receives the PT, it is allowed to send messages until it has finished
or until the “maximum token hold time” has expired, whichever is the shorter time.
Application Layer
The application layer in the FF specification is divided into two sub layers: the
Foundation. Fieldbus access sub -layer (FAS) and the Foundation Fieldbus messaging
specification (FMS).
Fieldbus Access Sublayer (FAS)
The FAS uses the scheduled and unscheduled features of the Data Link Layer to provide a
service for the Field bus Message Specification (FMS). The types of FAS services are described
by Virtual Communication Relationships (VCR).
The VCR is like the speed dial feature on your memory telephone. There are many digits to
dial for an international call such as international access code, country code, city code, and
exchange code and finally the specific telephone number.
This information only needs to be entered once and then a “speed dial number” is assigned.
After setup, only the speed dial number needs to be entered for the dialing to occur. Likewise,
after configuration, only the VCR number is needed to communicate with another field bus
device, a. Just as there are different types of telephone calls such as person to person, collect, or
conference calls, there are different types of VCRs.
The Client/Server VCR Type
*The Client/Server VCR Type is used for queued, unscheduled, user initiate one to one, and
communication between devices on the field bus. Queue: means that messages are sent and
received in the order submitted for transmission, according to their priority, without overwriting
previous messages.
*When a device receives a Pass Token (PT) from the LAS, it may send a request message to
another device on the field bus. The requester is called the “Client and the device that received
the request is called the “Server.” The Serve: sends the response when it receives a PT from the
LAS. The Client/Server VCR Type is used for operator initiated requests such as set point
changes, tuning parameter access and change, alarm acknowledge, anc device upload and
download.The Report Distribution VCR Type ,The Report Distribution VCR Type is used for
queued, unscheduled, use: initiated, one too many communications.
*When a device with an event or a trend report receives a Pass Token (PT) from the LAS, it
sends its message to a “group address” defined for its VCR Devices that are configured to listen
on that VCR will receive the report, a. The Report Distribution VCR Type is typically used by
field bus devices to send alarm notifications to the operator consoles.
The Publisher/Subscriber VCR Type
The Publisher/Subscriber VCR Type is used by the field devices for cyclic, scheduled,
publishing of User Application function block input and outputs such as process variable (PV)
and primary output (OUT) on the field bus. a The Publisher/Subscriber VCR Type is used for
buffered, one too many communications. Buffered means that only the latest version of the data
is maintained within the network. New data completely overwrites previous data, a When a
device receives the Compel Data (CD), the device will “Publish” or broadcast its message to all
devices on the field bus. Devices that wish to receive the Published message are called
“Subscribers”, The CD may be scheduled in the LAS, or it may be sent by Subscribers on an
unscheduled basis. An attribute of the VCR indicates which method is used.

FIELDBUS ACCESS SUBLAYER SERVICES

Field Bus Message Specification (FMS)

Field bus Message Specification (FMS) services allow user applications to send messages
to each other across the field bus using a standard set of message formats.FMS describes the
communication services, message formats, and protocol behavior needed to build messages for
the User Application

Data that is communicated over the field bus is described by an “objec description.” Object
descriptions are collected together in a structure called ac “object dictionary” (OD). The
object description is identified by its “index” in the OD. Index 0, called th; object dictionary
header, provides a description of the dictionary itself, an: defines the first index for the object
descriptions of the User Application. The User Application object descriptions can start at any
index above 255. A “Virtual Field Device” (VFD) is used to remotely view local device data
described in the object dictionary. A typical device will have at least two VFDs.
USER APPLICATION BLOCKS
The Fieldbus Foundation has defined a standard User Application based on “Blocks.” Blocks
are representations of different types of application functions.
Resource Block
The Resource Block describes characteristics of the fieldbus device such as the device
name, manufacturer, and serial number. There is only one resource block in a device.
Function Blocks
Function Blocks (FB) provide the control system behavior. The input and output
parameters of Function Blocks can be linked over the fieldbus. The execution of each Function
Block is precisely scheduled. There can be many function blocks in a single User Application.
 FIELDBUS
Fig. User Layers

Transducer Blocks decouple Function Blocks from the local input/output functions
required to read sensors and command output hardware. They contain information such as
calibration date and sensor type. There is usually one transducer block for each input or output
function block.

Network Management
Network Management is part of the Network and System Management Application. It
provides for the configuration of the communication stack.
The Virtual Field Device (VFD) used for Network Management is also used for System
Management. This VFD provides access to the Network Management Information Base (NMIB)
and to the System Management Information Base (SMIB). -
NMIB data includes Virtual Communication Relationships (VCR), dynamic variables,
statistics, and Link Active Scheduler (LAS) schedules (if the device is a Link Master).
SMIB data includes device tag and address information, and schedules for function block
execution. System Management is described further in the User Application section.
Communication Services
FMS communication services provide a standardized way for user applications such as
function blocks to communicate over the fieldbus.Specific FMS communication services are
defined for each object type. All of the FMS services can only use the Client/Server VCR Type
except as noted

Create Program Invocation Create a program object

Delete Program Invocation Delete a program object
Start Start a program
Stop Stop a program
Resume Resume program execution
Reset Reset the program
Kill Remove the program

The exact formatting of FMS messages is defined by a formal synta- description

language called Every fieldbus device must have a unique network address and physical device
tag for the fieldbus to operate properly.
To avoid the need for address switches on the instruments, assignment c: network
addresses can be performed automatically by System Management.
Device Descriptions
A critical characteristic required of fieldbus devices is interoperability. To achieve
interoperability, Device Description (DD) technology is used in addition to standard function
block parameter and behavior definitions.
The DD provides an extended description of each object in the Virtual Field Device (VFD) as
shown. The DD provides information needed for a control system or host to understand the
meaning of the data in the VFD including the human interface for functions such as calibration
and diagnostics. Thus the DD can be thought of as a “driver” for the device.
The DDs are similar to the drivers that your personal computer (PC) uses to operate different
printers and other devices that are connected to the PC. An> control system or host can operate
with the device if it has the device’s DD.
The DD is written in a standardized programming language known as Device Description
Language (DDL). A PC-based tool called the “Tokenizer” convert; DD source input files into
DD output files by replacing key words and standard strings in the source file with fixed
“tokens” as shown in Figure 3.24. a. The Fieldbus Foundation (FF) provides DDs for all standard
Function Blocks and Transducer Blocks. Device suppliers will typically prepare an
“incremental” DD which references the Standard DDs. a Suppliers may also add supplier
specific features such as calibration and diagnostic procedures to their devices. These features
can also be described in the incremental DD.
*The Fieldbus Foundation makes the Standard DDs available on a CD-ROM. The user can
obtain the incremental DD from the device supplier or from the Fieldbus Foundation if the
supplier has registered their incremental DD with the Fieldbus Foundation
The incremental DDs can also be read directly from the device over the fieldbus, if the device
supports the upload services and contains a Virtual Field Device (VFD) for the DD.
Device Description Services (DDS)
On the host side, library functions called Device Description Services (DDS) are used to read
the device descriptions
Note that DDS reads descriptions, not operational values. The operational values are read
from the fieldbus device over the fieldbus using FMS communication services.
* New devices are added to the fieldbus by simply connecting the device to the fieldbus wire
and providing the control system or host with the standard and incremental (if any) DD for the
new device, a DDS technology allows operation of devices from different suppliers on the same
fieldbus with only one version of the host human interface program, a The Fieldbus Foundation
has defined a hierarchy of Device Descriptions (DD) to make it easier to build devices and
perform system configuration.
The next level in the hierarchy is the Function Block Parameters. At this level, parameters are
defined for thestandard Function Blocks. Parameters for the standard Resource Block are also
defined at this level.

Hierarchy of functional blocks for Device Description Services The third level is called
Transducer Block Parameters. At this level, parameters are defined for the standard Transducer
Blocks. In some cases, the transducer block specification may add parameters to the standard
Resource Block.
The Fieldbus Foundation has written the Device Descriptions for the first three layers of the
hierarchy. These are the standard Fieldbus Foundation DDs.
The fourth level of the hierarchy is called Manufacturer Specific Parameters At this level,
each manufacturer is free to add additional parameters to the Function Block Parameters and
Transducer Block Parameters. These nev- parameters will be included in the “incremental” DD.
ta Each manufacturer will provide the Fieldbus Foundation with an interoperability test report
for each device.
The test report identifies the Universal, Function Block, Transducer Block, anc Manufacturer
Specific Parameters in the device.
An identifier called the Manufacturer’s Identification is used to correlate the device type and
revision with its Device Description and DD revision.
Any host using the Device Description Services (DDS) interpreter will be able to interoperate
with all parameters that have been defined in the device by reading the device’s DD.
INTEROPERABILITY
Interoperability and Spatial Data Standards The International Organization for
Standardization defines interoperability as “the capacity to communicate, execute programs, or
transfer data among various functional units in a manner that requires the user to have little or no
knowledge of the unique characteristics of those units” (ISO 1993). In the context of geographic
information, the functional units are geographic information (Gl) systems or Web services.
The communication between these units comprises transfer of spatial data as well as querying
and execution of remote services.
interoperability can be distinguished: syntactic interoperability refers to format of the
transferred data that is the compliance with spatial data standards; semantic interoperability
builds on syntactic interoperability and refers to the accurate preservation and interpretation of
the meaning of the transferred information.

FIGURE for Interoperability

 The focus of this entry is on syntactic interoperability and the standards enabling
heterogeneous GI systems and services to interoperate.

*Note that the kind of interoperability here relies on lower-level technical

interoperability, where established standards guarantee that a CD can be read in every CD drive,
computers can communicate through telephone wires, electric devices can be operated on every
power outlet, and so forth, a, Interoperability is a key requirement for the seamless exchange of
spatial data between users and organizations employing different GI systems and Web services. *
*On a broader scale, the standards enabling interoperability are the cornerstones of SDIs.
Without agreements on the formats of the transferred spatial data and the interfaces for
accessing the corresponding Web services, mutual data exchange between different GI systems
would at least require manual transformation of the data or even be impossible altogether,

.*The most important organizations that develop such standards for the geospatial domain are the
OGC and the ISO/TC211, responsible for geographic information / geomatics. Both
organizations have a working agreement, resulting in a frequent mutual adaptation of standards,
*. Data Interoperability before the Web became a common platform for the exchange of geodata,
interoperability mainly concerned the exchange of spatial data between different desktop GIS
workstations on different kinds of media.
*One such vendor-neutral standard for geographic features that is common' used today is the
Geography Markup Language (GML) introduced OGC. GML is an extensible Markup
Language (XML) encoding for th; transport and storage of geodata that can be tailored to
specific applications \ii application schemas.
*Application schemas define the specific feature types and property types tha: are relevant for
a given domain based on the GML meta schema. Due to the complexity of GML caused by this
multi-purpose design, numerous developers favored the simpler Keyhole Markup Language
(KML), especially for nonprofessional or Web 2.0 mash- ups. KML was originally a propriety
forma: used in Google Earth and has been put under control of the OGC in 2007. It became an
open OGC standard in 2008.
*Besides the actual data, their descriptions in metadata must also be standardized in order to
allow interoperable data discovery in catalogue services. This standardization refers to the
metadata encoding as well as the minimum set of mandatory properties, allowing for metadata
profiles for different applications.
The ISO 19115 specification provides such a standard specifically developed for metadata on
geodata. It comprises over 400 different elements, of which a small subset is compulsory.
Besides ISO 19115, the Dublin core metadata standard is also commonly used for spatial
information, although it is a general purpose standard, which has not been developed specifically
for geodata.
*Web Service Interoperability Web services enable loosely coupled service oriented
architectures that provide Internet-based access to spatial data stored in remote databases. They
allow for the execution of distributed geoprocessing functionality such as the online computation
of standard GIS operations. Inaddition to standards for the formatting of the transferred data,
Web services require standardized interfaces for the communication with these services.
The OGC has developed a number of standards for geospatial Web services, with the most
widely adapted being the Web Map Service (WMS) and Web Feature Service (WFS)
specifications for the retrieval of raster and vector data, respectively. Further specifications cover
advanced functionality such as geodata processing (WPS), sensor observation (SOS) or location
services (OpenLS). OGC specifications define Web service interfaces by specifying the formats
for requests and responses.
*This implementation- independent approach allows existing proprietary Web services to be
subsequently equipped with an additional OGC compliant interface. Such a mapping is
especially important for the integration of existing services into SDIs and follows an approach
that has proven useful on the technical level: for a user, it is sufficient to know the interface, such
as a power outlet or a WMS interface, and the corresponding interactions.

INTERCHANGEABILITY
Interchangeability is the feature of the network wherein devices from one manufacturer can
be replaced with functionally equivalent devices from other manufacturers.
Interchangeability of implementation: The ultimate goal of a unified network is to achieve
‘Interchangeability’, after due testing and certification of field devices and systems

INTRODUCTION TO OLE FOR PROCESS CONTROL

OLE for Process Control (OPC), which stands for Object Linking an; Embedding (OLE) for
Process Control, is the original name for a standard specification developed in 1996 by an
industrial automation industry tas? force. The standard specifies the communication of real-time
plant da*_ between control devices from different manufacturers.
The OPC Foundation has officially renamed the acronym to mean "Ope: Platform
Communications" although they also use the tagline "Ope: Productivity & Connectivity" on their
website. The change in name reflects the applications of OPC technology for applications in
Process Control, discrete manufacturing, building automation, and many others. OPC has also
grow- beyond its original OLE (Object Linking and Embedding) implementation t: include other
data transportation technologies including XML, Microsoft'; .NET framework, and even the
OPC Foundation's binary-encoded TCP format
After the initial release in 1996, the OPC Foundation was created to maintain the standard.
Since then, standards have been added and names have beer changed. As of June, 2006, "OPC is
a series of standards specifications' (Seven current standards and two emerging standards.) "The
first standar; (originally called simply the OPC Specification"), is "now called the Dat: Access
Specification", or (later on the same page) "OPC Data Access", or OPC Data Access
Specification.
ORIGIN AND USES
The OPC Specification was based on the OLE, COM, and DCOM technologies developed by
Microsoft for the Microsoft Windows operating system family. The specification defined a
standard set of objects, interfaces and methods for use in process control and manufacturing
automation applications to facilitate interoperability.
The most common OPC specification is OPC Data Access, which is used to read and write
real-time data. When vendors refer to OPC generically, they typically mean OPC Data Access
(OPC DA). OPC DA itself has gone through 3 major revisions since its inception.
Versions are backwards compatible, in that a version 3 OPC Server can still be accessed by a
version 1 OPC Client, since the specifications add functionality but still require the older version
to be implemented as well. However, a Client could be written that does not support the older
functions since everything can be done using the newer ones, so a DA 3 compatible Client will
not necessarily work with a DA 1.0 Server.
 In addition OPC DA specification, the OPC Foundation also maintains the OPC HDA
(Historical Data Access) specification. In contrast to the real time data that is accessible with
OPC DA, OPC HDA allows access and retrieval of archived data

DESIGN
OPC was designed to provide a common bridge for Windows based software applications and
process control hardware. Standards define consistent methods of accessing field data from plant
floor devices.
This method remains the same regardless of the type and source of data. An OPC Server for
one hardware device provides the same methods for an OPC Client to access its data as any and
every other OPC Server for that same and any other hardware device.
The aim was to reduce the amount of duplicated effort required from hardware manufacturers
and their software partners, and from the SCADA and other HMI producers in order to interface
the two.
Once a hardware manufacturer had developed their OPC Server for the n hardware device
their work was done to allow any 'top end' to access the - device, and once the SCADA producer
had developed their OPC Client their work was done to allow access to any hardware, existing or
yet to be creates with an OPC compliant server.
OPC servers provide a method for many different software packages (so lor.: as it is an OPC
Client) to access data from a process control device, such a PLC or DCS. Traditionally, any time
a package needed access to data from device, a custom interface, or driver, had to be written. The
purpose of OPC to define a common interface that is written once and then reused by am
business, SCADA, HMI, or custom software packages.
There is nothing in the OPC specifications to restrict the server to providing access to a
process control device. OPC Servers can be written for anything from getting the internal
temperature of a microprocessor to the curren: temperature in Monument Valley.
Once an OPC Server is written for a particular device, it can be reused by any application that
is able to act as an OPC client. OPC servers use Microsoft's OLE technology (also known as the
Component Object Model, or COM) to communicate with clients. COM technology permits a
standard for real-time information exchange between software applications and process hardware
to be defined.
It is important to note that some OPC specifications are published, others are available only
to member of the OPC Foundation. So whilst no company "owns" OPC and anyone can develop
an OPC server, whether or not they are a member of the OPC Foundation, non-members will not
necessarily be using the latest specifications. Anyone can integrate OPC products, and there is no
pre-requisite for the system integrator to belong to any organization. It is therefore up to each
company that requires OPC products to ensure that their products are certified and that their
system integrators have the necessary training.

FUTURE
The OPC Unified Architecture (UA) has been specified and is being tested and implemented
through its Early Adopters program. It can be implemented with Java, Microsoft .NET, or C,
eliminating the need to use a Microsoft Windows based platform of earlier OPC versions, UA
combines the functionality of the existing OPC interfaces with new technologies such as XML
and Web Services to deliver higher level MES and ERP support.