7-1

CHAPTER 7

FIELD BUSES
7.1. CAN (The Controller Area Network).
7.2. DeviceNet.
7.3. Foundation Fieldbus
7.4. PROFIBUS
7.5. Hart Communication Protocol
7.6. Modbus

PREVIEW
In this chapter, the most important and recent low level international instrumentation network
standards are presented. Section 7.1 introduces the industrial network CAN (Controller Area Network)
with its main features, CAN Network technology and HLP (Higher Layer Protocols). The essential
features of DeviceNet are given in Section 7.2. Foundation Fieldbus is detailed in Section 7.3 where
the 3 layers fieldbus model is presented. Section 7.4 covers PROFIBUS with its 3 compatible versions
DP, FMS and PA. In Section 7.5 the Hart Communication Protocol is presented in details. The
Appendix includes 3 informative tables on summary and comparison of Field Buses, Background
Information, and Physical Characteristics.

I N S T R U C T I O N A L O B J E C T I V ES
After reading this chapter, you should be able to

• Describe the architecture of the most popular industrial FieldBuses.

• Discusses their various protocols.
• Give the main features of each Bus.
• Determine the domain of application of the different Buses.
• Determine technical specifications for each Bus.
• Give examples of how a given Bus is implemented in an industrial application.
• Contrast the transport mechanism of different Buses.
• Give the physical characteristics of each Bus.

Dr. Moustafa Elshafei

 7-2

INDUSTRIAL FIELD BUSES

There are many available industrial networks designed to meet differing application
requirements. For example, a simple on/off switch on a conveyor belt has different
communication requirements than a complex control valve in a petroleum refinery. It is
important to understand the target application of a network in order to choose the right
network for a given application.
The following sections are introductions to some of these industrial networks

7.1 CAN (The Controller Area Network)

CAN was developed in the late 80’s by Robert Bosch1 as a solution for networking in
distributed real-time systems. CAN supplies a high level safety, even when working in a
harsh environment, and can support transmission speeds up to 1 Mbit/s. One of the most
important features of the CAN technology is the guaranteed maximal latency for bus access
that makes it the choice for real-time systems. The CAN protocol becomes an ISO standard
for serial data communication, ISO 11898 for high speed up to 1Mbps and true plug and play,
and ISO 11519 for low speed up to 125 kbps. The CAN protocol was developed aiming at
automotive applications. Today CAN has gained widespread use. It is currently used in
industrial automation as well as in automotive and mobile machines, and becomes more and
more popular in additional fields such as textile industry, medical equipment, and elevator
controls. The CAN features also a low cost and ease of operation and maintenance. CAN
controllers are available off the shelf at very low cost from many semiconductor
manufacturers. The main Features of ISO 11898 can be summarized as follows:
• Topology: Bus terminated on both sides.
• Bus medium: twisted -pair cable.
• Transfer mode: serial asynchronous data transfer, multimaster capability, baseband
transfer, NRZ coding with bit-stuffing.
• Bus Access Procedure: Non-destructive CSMA/CD, bit-wise arbitration.
• Transmitter output level : differential similar to RS-485.
• Max. number of nodes : up to 64 (Practical limit).
• A non-destructive bitwise arbitration is used to control access to the bus.
• Message length: 0-8 data bytes.
• Message addressing: There is no explicit address in the messages; instead, each message
carries a numeric identification code value which controls its priority on the bus.
• Error handling: an elaborate error handling scheme that results in retransmitted messages
when they are not properly received. There are effective means for isolating faults and
removing faulty nodes from the bus.
• Transmission Rates: 1 Mbps up to 40 meters, 500 kbps up to 100 m, 250 kbps up to 200
meters, 125 kbps up to 500 meters, and 10 kbps up to 6 km.

CAN Network Technology

CAN handles the lower two layers of ISO reference model in a similar structure to
IEEE802.3 format. It defines a Physical, MAC (media access control, and LLC ( logical link

1
Robert Bosch, CAN Specifications Version 2.0, BOSCH, Stuttgart, 1991.

Dr. Moustafa Elshafei

 7-3
layer) layers. The CAN standard includes a physical layer and a data-link layer which
defines a few different message types, arbitration rules for bus access and methods for fault
detection and fault confinement.
The function of the Physical layer is, as in any other network technology, to transfer the
bits from one destination to another. The Medium Access Control sublayer of the Data Link
layer has the function to control frames, checking and signalling for errors, performing the
needed operations for accessing the bus, discovering faults and signalling for them. The
Logical Link Control sublayer of the Data Link layer has to filter incoming messages, to
provide services for data transfer and data requests, to provide means for recovery
management and overloading notification.
However, current ISO implementations are based on twisted pair cable. What is
important, is that there are two signal lines, termed CAN H and CAN L. A dominant (logical
0) bit has CAN H higher than CAN L, and a recessive (logical 1) bit, in opposite, CAN H
lower than CAN-L as shown in Figure 7.1 This mechanism yields to a reliable data transfer,
even in an extremely harsh electrical environment.
The MAC Sublayer uses CSMA/CD as Ethernet, but they differ in the way the collision is
handled. In the Ethernet, if collision is detected, each transmitting station performs Backoff,
and tries to transmit again after a random period of time. This mechanism is called
destructive bus allocation, since all transmission are aborted. There is no guarantee for any
computer that in the next time the bus will be free and there will be no collision.
Theoretically, there is no an upper bound for the latency of the bus access, and also after each
collision the bus remains idle for certain amount of time.

Node 1 Node 2

CPU CPU

CAN CAN
Controller Controller

CAN_H

Bus Bus
CAN_L
termination termination

FIGURE 7-1 CAN uses bus topology using terminated twisted pair cable.

CAN uses CSAM/CD with Non-Destructive Bitwise Arbitration mechanism which ensures
a low latency in a bus allocation for "important" messages, and also maximal bus utilization.
First of all, in contrast to the Ethernet, the CAN communication is data-oriented (or content-
oriented), and not destination-oriented. This means that frames are not sent to a specific
destination, but they are identified according to the data they carry. The frame identifier
defines also the data priority. When two nodes start transmission at the same time, they can't
discover the problem until one of them tries to transmit 0 (dominant bit) and the second - 1
(recessive bit). In this case what is actually goes on the line is 0, and the node that tried to
transmit 1 monitors 0 and recognizes a collision. It stops immediately the transmission .The
node that tried to transmit 0, monitored 0, and thus didn't feel any problem and continued

Dr. Moustafa Elshafei

 7-4
transmitting. It's important to mention that the identifiers of the data are unique, and it's
impossible that two nodes try to transmit data with the same identifier.

The frame format is different from the Ethernet structure. There are two frame formats in
the current CAN 2.0, standard frame format (compatible with CAN 1.0) CAN 2.0A, and
extended frame format CAN 2.0B. The first one uses 11 bit identifier field, while the later
one uses an additional 18 bit identifier field. Each frame starts by a single SOF bit, and ends
with 7 recessive bits. The data field can be from 0-8 bytes. The frame contains as well a 15-
bit error checking field using Cyclic-Redundancy Check (CRC), and other predefined bits
and fields as shown in Figure 7.2.

Message Frame

Arbitration field Control Data field CRC field ACK EOF

S R I I
Bus 11 bit r 0-8 bytes 15 bit
O T D DLC N Bus idle
idle identifier 0 Data CRC EOF
F R E T

CRC ACK
Delimiter Delimiter
ACK
Slot

(a)

Message Frame

Arbitration field Control Data field CRC field ACK EOF

S 11 bit S I R I
Bus 16 bit r r 0-8 bytes 16 bit
O Identifie R D T DLC EOF N Bus idle
idle Identifier 1 0 Data CRC
F r R E R T

CRC ACK
Delimiter Delimiter
ACK
(b) Slot

Data Frame Formats: (a) Standard Frame Format ; (b) Extended Frame
Format

Figure 7-2 Frame structure in (a)CAN 2.0A, and (b) CAN 2.0B.

One of the most powerful feature of CAN, is its overall error checking mechanism, which
includes a number of fixed bits to validate the frame structure, the CRC, node to node
protocol, and error monitoring, and confinement mechanisms. Since 1994, several higher-
level protocols have been standardized on CAN, such as CANopen and DeviceNet. Other
markets have widely adopted these additional protocols, which are now standards for
industrial communications.

The pinout for the 9-pin D connector is shown in the table below. Many of the additional
connector pin outs are used with CANopen and include: 10-pin header [5 x 2 multipole],
RJ10 [Modular Connector Jack], RJ45 [Modular Connector Jack], 5-pin mini [circular], 5-pin
micro [circular], Open Style, 7/8/9-pin round connectors.

Dr. Moustafa Elshafei

 7-5
Table 1 9 Pin (male) D-Sub CANbus PinOut

Pin # Signal Names Signal Description

1 Reserved Upgrade Path

2 CAN_L Dominant Low

3 CAN_GND Ground

4 Reserved Upgrade Path

5 CAN_SHLD Shield, Optional

6 GND Ground, Optional

7 CAN_H Dominant High

8 Reserved Upgrade Path

9 CAN_V+ Power, Optional

Some systems may use pin 8 as an error line, to indicate an error on the net.

Higher Layer Protocols (HLP)

The CAN protocol itself just specifies how small packets of data safely may be transported
from point A to point B using a shared communications medium. It contains nothing on
topics such as flow control, transportation of data larger than can fit in a 8-byte message,

Dr. Moustafa Elshafei

 7-6
node addresses, establishment of communication, etc. These topics are covered by a HLP
(higher layer protocol). The term HLP is derived from the OSI model and its seven layers.
Higher layer protocols are used in order to standardize startup procedures including arbitrate
setting distribute addresses among participating nodes or kinds of messages determine the
layout of the messages provide routines for error handling on system level. Figure 7.3
illustrates the network layer structure of CAN. The services of the application layer are
summarized below.

♦ The application layer provides a set of services and protocols useful to every device on the
network imaginable.

♦ The communication profile provides the means to configure devices and communication
data and defines how data is communicated between devices.

♦ Device profiles add device-specific behaviour for (classes of) devices (e.g. digital I/O,
analog I/O, motion controllers, encoders, etc.).

For more info http://www.educypedia.be/computer/datacommunicationbuscan.htm

7.2 DeviceNet
Originally developed by Allen-Bradley, DeviceNet is managed by the Open DeviceNet
Vendors Association (ODVA)2, an independent supplier organization. DeviceNet is a low
level network designed to connect industrial devices (sensors, actuators) to higher-level
devices (controllers). DeviceNet focuses especially on the interchangeability of very low-
cost, simple devices often used in manufacturing applications, such as limit switches,
photoelectric sensors, motor starters, bar code readers, variable frequency drives, motor
starters, etc. it is based on Producer/Consumer model. DeviceNet is standardized in the
international standard series IEC 61158. DeviceNet devices are certified for interoperability
and conformance to the DeviceNet standard by ODVA.
DeviceNet builds upon the CAN (Controller Area Network) described in the previous
section. While CAN specifies only portions of the Physical Layer and Data Link Layer
(layers 1 and 2), DeviceNet adds the remainder of these two layers, plus the Media Layer and
Application Layer. Layers 3-6 were not explicitly specified.

The main features of DeviceNet

• Basic Bus topology.
• Separate twisted-pair buses for both signal and power distribution, with signal and power
carried in the same cable, (shielded cable).
• Hot insertion of devices without removing power from the network.
• Optional opto-isolated design so externally-powered devices can share bus cable with bus-
powered devices.
• Data rates 125kbps (up to 500 m), 250kbps (up to 250 m), and 500kbps (up to 100 m).
• Maximum drop length is 6 meters.
• Up to 64 node addresses on a single network.
• Prioritized, Peer-to-Peer communication based on the non-destructive bitwise arbitration
scheme of CAN protocol.
• Producer-Consumer Model for data transfer.

2
Www.odva.org

Dr. Moustafa Elshafei

 7-7

While CAN specifications define the form of data movement, the DeviceNet Application
Layer (ISO layer 7) defines the semantics of the data on the network. DeviceNet
specifications were based on the Object Oriented notations that will be introduced later in this
chapter. In order to ensure compatibility between devices, each device usually comes with
built in (in Electronic form) the device profile in a pre-specified format. The format includes
the definition of the device object model, definition of the device I/O data format, and
definition of the device’s configurable parameters. The device object model specifies the
device operation in terms of a limited set of special objects or functions, e.g., Identity Object
(specifies vendor ID, device type, product code, serial number etc.), and Device Net Object
(defines node address, baud rate, Bus-off action, Bus-off counter, etc.), Connection Object,
Message Route Object, and Parameter Object.
DeviceNet is a digital, multi-drop network that connects and serves as a communication
network between industrial controllers and I/O devices. Each device and/or controller is a
node on the network. DeviceNet is a producer-consumer network that supports multiple
communication hierarchies and message prioritization. DeviceNet systems can be configured
to operate in a master-slave or a distributed control architecture using peer-to-peer
communication. DeviceNet systems offer a single point of connection for configuration and
control by supporting both I/O and explicit messaging. DeviceNet also has the unique feature
of having power on the network. This allows devices with limited power requirements to be
powered directly from the network, reducing connection points and physical size.

DeviceNet uses a trunk-line/drop-line topology that provides separate wire pairs for both
signal and power distribution. Thick or thin cable can be used for either trunklines or
droplines. End-to-end network length varies with data rate and cable thickness.

Terminator Extender Tap Terminator

Drop Line

Nodes

Zero Drop Short Drops

DeviceNet uses the Common Industrial Protocol, called CIP, for its upper protocol layers.
CIP is strictly object oriented. Each object has attributes (data) and services (commands) and
behavior (reaction to events). Two different types of objects are defined in the CIP
specification: communication objects and application-specific objects. Vendor-specific
objects can also be defined by product vendors for situations where a product requires
functionality that is not in the specification.

Configuration with EDS-Files

During the setup phase of the DeviceNet network, the DeviceNet Master Scanner must be
configured with a special configuration tool. The configuration process is based on electronic
device data sheets (EDS-Files) which are required for each DeviceNet device. EDS-Files are

Dr. Moustafa Elshafei

 7-8
provided by the device manufacturers and contain electronic descriptions all relevant
communication parameter and objects of the DeviceNet device.
DEVICENET FACTS
Network Type: CAN-based Producer/Consumer Fieldbus communication system
Topology: Bus line with trunkline/dropline topology
- Shielded cable with 2 pairs of 2 wires each
- Cable contains data and 24 Volt bus power on separate wires
Installation:
- Connection via pluggable screw terminals or M12 connectors
- Segment length depending on cable and baudrate 100 - 500m
Speed: 125 - 500 kbit/s
max. Stations : 64
- max. 8 Byte per telegram frame
Data :
- larger data packages require segmentation
Field level communication system of the CIP network family, providing
Network Features :
advanced communication features for field devices
User Organization: Open DeviceNet Vendors Organization (ODVA)

Dr. Moustafa Elshafei

 7-9

7.3 Foundation Fieldbus

FOUNDATION Fieldbus3 is an industrial network designed specifically for distributed

process control applications. This network was created by the Fieldbus Foundation, an
organization of more than 100 companies that make up more than 80 percent of the world’s
supply of automation systems, devices and services. Specifications of the FFB were released
in 1996 for the low speed field bus (H1) 31.25 kbit/s, and the high speed field bus (H2) 1.0
Mbit/s and 2.5 Mbit/s fieldbus, and details of the fieldbus’ Data Link Layer, Application
Layer, and System Management and Network Management functions.
The Foundation requires that vendors must register their field and host devices with the
Foundation. The Fieldbus Foundation's product registration is granted through extensive
testing procedures to ensure that a Foundation-registered host or field device will
communicate and fully interoperate with any other registered device.

Bridge
HSE H2-H1
H1

H1
Feildbus I/O
H2

Junction
Box

H1

H1
H1

Point - to - Point Bus with spurs Daisy - Chain Tree

Figure 6-3
Foundation Fieldbus is based on existing technologies where possible, including work of the
ISA (International Society for Measurement and Control) ISP50.02-1992, and the IEC
(International Electrotechnic Committee) standards IEC1158-2-1993. The Data Link Layer
DLL and the Application Layers conform to the International IEC 61158 fieldbus standard.
The Foundation has also recently standardized a 100 Mbps High Speed Ethernet (HSE),

3
www.fieldbus.org

Dr. Moustafa Elshafei

 7-10
based on the open, commercial, high-speed Ethernet technology. Additional elements of the
recommendations will provide redundant Ethernet physical media and multiple linking
devices in order to meet the robust requirements of mission-critical applications.

FFB Network model

The field bus model consists of 3 layers:
(a) the Physical Layer corresponding to the ISO layer 1.
(b) the Communication “Stack” corresponding to layers 2 and 7 in the ISO model.
(c) the User Layer.
Figure 3 shows these components compared to the OSI 7-layer communication model.
FFB does not implement layers 3,4,5 and 6 of the OSI model because the services of these
layers are not required in a process control application, however, a very important part of
Foundation Fieldbus is the User Layer.
Feildbus Architecture
Maintenance
Workstation
Information
System

User Layer

System Management
Network Management
ISO Layer 7 Application Layer

ISO Layer 2 Data Link Layer

ISO Layer 1 Physical Layer

Level
Multivariable Valve Transmitter Pump
Transmitter
Figure 6-4

Physical Layer
Foundation Fieldbus uses the physical layer (electrical, wiring, and so on) standardized by
ISA/IEC (ISA SP50.02-1992, IEC 1158-2). Table 4 summarizes the main characteristics of
this standardized physical layer.
H1 H2 1Mbps H2 2.5 Mbps
Topology Bus/Tree Bus Bus
Devices 2-32 2-32 2-32
Bus-powered devices 2-13 none none
Bus powered IS devices 2-6 none none
Max distance using shielded twisted- 1900 m. 750 m. 500 m.
pair cable STP.
Spur length. 120 m. non. non
Table 4. Summary of IEC-1158 Physical Layer Characteristics

Dr. Moustafa Elshafei

 7-11
A Spur is a length of fieldbus network between a junction box and a device.
Several key characteristics to point out are:
• Several communication data rates, including a low speed that is compatible with existing
twisted-pair 4-20 mA wiring, as shown in Table xxx..
• Devices draw their operating power from the same two wires as the signal, removing the
need for external power supplies, as shown in table xxx.
• Supports bus and star topology.
• Capability for intrinsically safe operation, a requirement for hazardous environment.

Communication Stack
The Communication Stack performs the services required to interface the User Layer to
the Physical Layer. Several characteristics and functions of the Data Link Layer, however,
are key to the distributed, real-time capabilities of Foundation Fieldbus:
Data Link Layer
• The Data Link Layer is a token-passing protocol.
• The Link Active Scheduler (LAS) is a device that acts as the centralized arbitrator of the
bus.
• The LAS executes a schedule that makes possible deterministic control and
communication.
• The LAS distributes time to the bus to permit all devices to share the same sense of time.
• Control can be passed between multiple Link Masters (devices capable of being the LAS),
providing redundancy on the fieldbus. If one LAS fails, one of the other LMs will become
the LAS..

Application Layer
H1 and HSE use a common layer 7 interface to the user layer. In H1 the services are defined
by the Fieldbus Message Specification (FMS). In HSE the services are defined by the Field
Device Access (FDA) Specification.
FMS and FDA provide the same Client/Server, Publisher/Subscriber, and Event Notification
communication services.
Client/Server is typically used for request/response communication between hosts and field
devices.
Publisher/Subscriber services are used for transfer of cyclic data between function blocks
and for data acquisition by a host.
Event Notification services are typically used by the devices for sending alarm and trend
information to the hosts.

In H1, the lower sublayer of the application layer is called Fieldbus Access Sublayer (FAS).
The Fieldbus Access Sublayer (FAS) maps the Fieldbus Message Specification (FMS) onto
the Data Link Layer (DLL).

Fieldbus Messaging Specification (FMS)

The Fieldbus Messaging Specification (FMS) contains definitions of Application Layer
services in FOUNDATION fieldbus. The FMS specifies services and message formats for
accessing Function Block (FB) parameters, as well as Object Dictionary (OD) descriptions
for those parameters defined in the Virtual Field Device (VFD).

Dr. Moustafa Elshafei

 7-12

User Layer
FFB defines a unique communication layer called the User Layer. The User Layer does not
exist in the ISO communication stack model.
The device functions are made visible to the fieldbus communication system through the
User

Dr. Moustafa Elshafei

 7-13
Application Virtual Field Device (VFD).

Virtual Field Device (VFD)

A Virtual Field Device is a model of the device for communications purposes. It groups
variables into objects and then allows access to the data via an individual object dictionary
(OD) for each VFD. This grants easy access to complex functions built up in a VFD. A
physical device can contain one or more VFD. A VFD is built using Functions Blocks and
an Object dictionary.

The FMS specifies services and message formats for accessing Function Block (FB)
parameters, as well as Object Dictionary (OD) descriptions for those parameters defined in
the Virtual Field Device (VFD). This layer is NOT the process application. It is the
responsibility of this layer to provide protocols/services both internally within and between
devices on a fieldbus. For FOUNDATION fieldbus the Application layer is described in two
parts, the Fieldbus Message Specification Layer (FMS) and the Fieldbus Access Sublayer
(FAS).

Object Directory (OD)

Provides a standard structure for accessing the internal data of a device. It defines the data
types e.g. Integer, Boolean, Float, Date, String etc. The OD resides at the Application Layer.
The OD is read by systems which then use the indices to access the data.
Device Description (DD)
Device descriptions are provided to host systems so that the host can "interpret"the meaning
of the data provided by fieldbus devices. The DD knows the indices in the Object Dictionary
of the device, so the host can use it to access variables. The DD is a clear unambiguous
structured text description that precisely describes the field device data and operations to host
systems. This text file is then passed to a tokenizer tool that generated the binary DD used by
the host.

The User Layer defines an interface by which users of Foundation Fieldbus can communicate
with devices through a set of blocks rather than as a collection of simple data points. Three
types of blocks make up the Foundation Fieldbus User Layer:
Resource Block - describes characteristics of device such as name, manufacturer, and
serial number.
Function Blocks - provide the control and I/O behavior of a device.
Function Block Name Symbol
Analog Input AI
Analog Output AO
Bias B
Control Selector CS
Discrete Input DI
Discrete Output DO
Manual Loader ML
Proportional/Derivative PD

Dr. Moustafa Elshafei

 7-14
Proportional/Integral/Derivative PID
Ratio RA

Transducer Blocks - decouple Function Blocks from the functions required to read /
write local inputs / outputs.
Foundation Fieldbus defines standard sets of Function Blocks, of which there is a set of 10
for the most basic of control and I/O functions (see Table 5). Other function blocks are being
defined both by the Foundation and by individual manufacturers.
Users create applications on the fieldbus by connecting together the inputs and outputs of
function blocks. In addition to specifying how these blocks “talk” to one another over the
bus, Foundation Fieldbus also specifies how you can precisely schedule the time at which
these blocks execute. The Function Blocks themselves reside in individual devices but the
overall scheduling of execution is specified and executed across the network. Figure 5 shows
a PID control loop for flow control and comparators for high alarm and low alarm. The figure
uses To achieve distributed control, functions such as an Analog Input (AI) in a flow
transmitter or an Analog Output (AO) in a valve are encapsulated in function blocks.
Functions such as Proportional Integral Derivative (PID) control can also be built into
function blocks and run in a field device. In figure 3, the PID and AO blocks are running in
the valve.

For basic control blocks the number and type of inputs and outputs are pre-defined by the
FOUNDATION fieldbus™ specification. For more complex functions such as batch control,
coordinated drive control, I/O gateways, and PLC sequencing, a special Flexible Function
Block (FFB) can be used. The inputs and outputs of the FFB, and the FFB control algorithm
are configurable by the end user four Function Blocks ; AI, PID, and AO, and CMP.
Because of the ability to interconnect different functions, even control algorithms, that
reside with the field devices themselves, Foundation Fieldbus actually provides an
architecture for distributing control into the field rather than concentrating the control in
centralized controllers.

Figure 6-5

Flexible Function Blocks (FFB)

In addition to standard function blocks,vendors are able to define their own blocks for
vendor-specific purposes. These blocks are called Flexible Function Blocks. A Flexible
Function Block (FFB), defined in FF-894 FBAP part 5, is an application-specific Function
Block, whose input, output and contained parameters depend on its actual algorithm. The

Dr. Moustafa Elshafei

 7-15
definition of Flexible Function Blocks is independent of the programming language of the
algorithm and the device structure. It might thus be used for a wide range of different
programming systems, even though it is designed to fulfil the specific requirements of the
Manufacturing Automation world and they ’re standardized programming language defined
in IEC 61131-3.6.2.3.2.1

Device Description
A second important feature of the Foundation Fieldbus User Layer is Device Descriptions.
A Device Description (DD) is a standardized description of the functions available in a
device. Because it actually describes a device’s functions, the DD is a standard way that any
host system can learn about the capabilities of the device. Even if the device contains a brand
new capability never before seen in such a device, as long as the capability is included in the
DD, the host can access it. Thus, systems and devices, even those containing completely
unique functionality, can interoperate by means of the DD.

FOUNDATION fieldbus™ specifies twenty-one standard function blocks designed to

address basic and advanced process control applications and more blocks are in development.
The flexible function blocks (FFB) mentioned earlier, are application-specific and are
designed to implement control strategies such as supervisory data acquisition, batch control,

Dr. Moustafa Elshafei

 7-16
PLC sequencing, burner management, coordinated drives, and advanced I/O interfacing.

Enhanced DDL (EDDL) (display of wave forms, charts, device specific information)
Device Description Language (DDL)

Field Device Tool (FDT)

Device Type Manager (DTM). (device driver)

DDL is Open, interoperable, standards-based. DDL technology is proven; it is employed in

the millions of Hart, Profibus DP and Foundation fieldbus devices installed by users.
IEC61804-2 DDL international standard,
DDL provides underlying technology for use by host suppliers to design robust human
machine interface (HMI) and automation interfaces, and enhancements being developed will
add to this functionality.

DDL-based field devices from all suppliers will interface identically to the various hosts.
DDL Maintains operating system and protocol independence.

FDT that is a "software receptacle" into which a DTM is "inserted".

The FDT provides interfaces to the software architecture of the host system; it becomes an
integral part of the host system.

The FDT provides access to underlying services such as display, keyboard, database (if there
is one), and other generic host features; it also provides access to any digital communication
interfaces the host system might have.

The FDT specification requires implementation to be accomplished with a Microsoft

Windows operating system (OS) and is built on Microsoft's Component Object Model
(COM) and Distributed Component Object Model (DCOM) technology.

Since COM/DCOM does not support real-time data exchange, these technologies have been
extended to accommodate this requirement.

The FDT is intended to provide interface to the Hart, Foundation fieldbus and/or Profibus
communication drivers if they are present in the host system.

At present, only Hart and Profibus are supported by the Joint Interest Group

Dr. Moustafa Elshafei

 7-17

7.4 PROFIBUS4
PROFIBUS is a leading open fieldbus system in Europe, is used worldwide in
manufacturing, process, and building automation. PROFIBUS is standardized in the German
standard DIN 19245 and European fieldbus standard EN 50170. PROFIBBUS technology is
developed and administered by the PROFIBUS User Organization, with a membership of
more than 600 manufacturers, users and research institutions.
Designed to meet a variety of application requirements, PROFIBUS can be used for both
high-speed time-critical data transmission between controllers and I/O, and complex
communications between programmable controllers. The PROFIBUS family consists of three
compatible versions - DP, FMS, and PA. These three protocols are described briefly in the
following sections.

Area
Controller

Factory MMS, TCP/IP Backbone

level

Bus cycle
time
<1000 msec
CHC

Host

PC

Cell
PROFIBUS - FMS
level

Bus cycle
time
<1000 msec PLC DCS

PC

Feild PROFIBUS - DP PROFIBUS - PA

Bus

Bus cycle
Feild Trans - Feild
time Drive I/O Valves
device mitter device
<1000 msec

Figure 6-6

4
www.profibus.com

Dr. Moustafa Elshafei

 7-18

Protocol Architecture
Figure 7.7 shows the architecture of PROFIBUS protocols using the OSI 7-Layer model.

FMS DP PA

DP-Profiles PA-Profiles
Layers FMS
Device
Profiles
DP-Extensions
User
DP Basic Functions

Application Feildbus Message

(7) Specification(FMS)

(3) - (6)
not used

Data Link
IEC Interface
(2)
Feildbus Data Link (FDL)

Physical
IEC 1158-2
(1) RS-485 / Fiber Optic

Figure 6-7 Protocol architecture of PROFIBUS

PROFIBUS-DP
PROFIBUS-DP is designed for high speed, cost-effective communication between
industrial controllers and distributed I/O; it can replace parallel signal transmission with 24 V
or 0 to 20 mA. On a PROFIBUS-DP network, central controllers, such as PLCs, or PCs,
communicate with distributed field devices (such as I/O devices, drives, and valves) via a
high-speed serial link. Most of the data communication with these distributed devices is done
in a cyclic manner.
PROFIBUS-DP uses Layers 1 and 2, and the user interface (Figure 12.7). Layers 3 to 7 of
the OSI model are not defined. The Direct Data Link Mapper (DDLM) gives access between
the user interface and Layer 2. The user interface specifies both application functions that are
available to the user and system and device behaviour of the PROFIBUS - DP device types.
RS-485 and fiber-optic are available physical media for PROFIBUS-DP.

PROFIBUS-FMS

Dr. Moustafa Elshafei

 7-19
PROFIBUS-FMS is designed for general purpose communication primarily between
programmable controllers, such as PLCs and PCs. FMS contains an application layer with
communication service available to the user. These services make it possible to access
variables, transmit programs, and control program execution as well as transmit events.
PROFIBUS-FMS defines a communication model in which distributed application processes
can be unified into a common process by using communication relationships.
In PROFIBUS-FMS, Layer 1, 2 and 7 are defined (Figure 6). The application layer
consists of FMS (Fieldbus Message Specification) and LLI (Lower Layer Interface). FMS
contains the application protocol and provides the user with a wide selection of
communication service. LLI implements communication relationships and provides FMS
with device-independent access to Layer 2. Layer 2 (FDL, Fieldbus Data Link) implements
bus access control and data security. RS-485 and fiber-optic physical layers are available for
PROFIBUS-FMS.

PROFIBUS-PA
PROFIBUS-PA is designed specifically for process automation, using the international
fieldbus standard physical layer (IEC 1158-2) for bus-powered sensors and actuators to be
operated in intrinsically safe areas. PROFIBUS-PA uses the extended PROFIBUS-DP
protocol for data transmission. Using the IEC 1158-2 physical layer, field devices can be
powered over the bus. PROFIBUS-PA devices can be integrated in PROFIBUS-DP networks
by the use of segment couplers.
Frofibus distinguishes between master devices and slave devices.
Master devices determine the data communication on the bus. A master when it holds the
“token” can send messages without an external request. Masters are also called active
stations.
Slave devices are peripheral devices. Typical slave devices include I/O devices, valves,
derives, and measuring transmitters. Slaves do not have bus access rights and they can only
acknowledge received messages or send messages to the master when requested to do so.
Slaves are called passive stations.

RS-485 Physical Layer for PROFIBUS-DP/FM

RS-485 is the physical layer most frequently used in PROFIBUS applications. Baud rates
of 9.6 kb/s to 12 Mb/s can be used; one transmission speed is selected for all devices on the
bus when the system is commissioned. Up to 32 stations can be attached to each segment
without repeaters, and up to 127 stations can be attached with repeaters. The operating
distance range from 100 m at 12Mbps to 1200 m at 9.6 kbps.

7.5 Hart Communication Protocol

HART is an acronym for "Highway Addressable Remote Transducer". HART was
developed by Rosemount Inc. in the mid-1980’s, but has been made completely open, and all
rights now belong to the independent HART Communication Foundation5. It is widely
accepted in the industry as a de facto standard for digitally enhanced 4-20mA
communications with smart field instruments. The HART protocol was designed specifically
for use with intelligent measurement and control instruments which traditionally
communicate using 4-20mA analogue signals. HART preserves the 4-2OmA signals and
enables two-way digital communications to occur without disturbing the integrity of the 4-
20mA signals. The HART protocol permits the process variable to continue to be transmitted
by the 4-2OmA analogue signal, and additional information pertaining to other variables,
5
www.hartcomm.org

Dr. Moustafa Elshafei

 7-20
parameters, device configuration, calibration, and device diagnostics to be transmitted
digitally at the same time
The HART Protocol uses the Open Systems Interconnection (OSI) reference model as a
guide. However, it implements only layers 1,2 and 7, i.e. the Physical layer, the Data Link
layer, and the Application layer.
The Physical Layer 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-2OmA as shown in
Figures xxx . The HART protocol communicates at 1200 bps without interrupting the 4-
2OmA signal and allows a host application (master) to get two or more digital updates per
second from a field device. As the digital FSK signal is phase continuous, there is no
interference with the 4-2OmA signal.
The bit stream is encoded into two sinusoidal tones. A “1” bit is represented by a 1200 Hz
tone, and a “0” bit is transmitted by a 2200 Hz tone. Cable length can be up to 1500 m if
24AWG Multiple twisted pair with common shield. And up to about 3,000 meters using
20AWG single twisted pair with shield. Table xxx gives the allowable cable length for versus
the number of devices. The HART protocol permits all digital communication with field
devices in multidrop network configurations. In conventional point-to-point mode, the 4-20
mA signal continues to be used for analog transmission, while other data can be transferred
digitally. In the mult-drop mode, up to 15 devices can be connected on a single pair of wires.
In multidrop mode, device address can be from 1-15, and each device sets its current output
at a fixed value of 4.0 mA.

The Data Link Layer (DLL) is responsible for the reliable transmission of data packets
across the network.
HART is a master/slave, character oriented, protocol which means that a field (slave) device
only speaks when spoken to by a master. HART provides for up to two masters (primary and
secondary) as shown in Figure xxx. This allows secondary masters such as handheld
communicators to be used without interfering with the master operation.
The DLL defines HART message structure. A HART message consists of synchronous 8-
bit data bytes organized into frames. . The message structure is shown in Figure xxxx.
The preamble, 5-20 bytes of hex FF (all 1's), helps the receiver to synchronise to the
character stream.
The start character may have one of several values, indicating the type of message: master
to slave, slave to master, or burst message from slave; also the address format: short frame or
long frame.
The address field includes both the master address (a single bit: I for a primary master, 0
for a secondary master) and the slave address. In the short frame format, the slave address is
4 bits containing the "polling address" (O to 1 5). In the long frame format, it is 3 8 bits

Dr. Moustafa Elshafei

 7-21
containing a "unique identifier" for that particular device. (One bit is also used to indicate if a
slave is in burst mode.)
The command byte contains the HART command for this message. Universal Commands
are in the range 0 to 30; Common Practice Commands are in the range 32 to 126; Device-
Specific Commands are in the range 128 to 253. We will talk about these commands shortly.

Figure 6-8
The byte count byte contains the number of bytes to follow in the status and data bytes.
The receiver uses this to know when the message is complete. (There is no special "end of
message" character.)
The status field (also known as the "response code") is two bytes, only present in the
response message from a slave. It contains information about communication errors in the
outgoing message, the status of the received command, and the status of the device itself.
The data field may or may not be present, depending on the particular command. A
maximum length of 25 bytes is recommended, to keep the overall message duration
reasonable. (But some devices have device-specific commands using longer data fields.)
Finally, the checksum byte contains an "exclusive-or" or "longitudinal parity" of all previous
bytes (from the start character onwards). Together with the parity bit attached to each byte,
this is used to detect communication errors.
Transactions usually consist of a Master command ands slave response pair. The integrity
of HART communication is very secure as status information is included with every reply
message and extensive error checking occurs with each transaction. Up to four process
variables can be communicated in one HART message and each device may have up to 256
variables.
The Application Layer defines the semantics of these messages and commands.
The HART Command Set is organized into three groups and provides read/write access to
the wealth of additional information available in smart field instruments employing this
technology. Universal Commands must be implemented by all HART devices and provides
interoperability across the large and growing base of products and manufacturers. The
HART Application Layer (OSI Layer 7) consists of three classes of commands or messages:
Universal Commands, Common Practice Commands, Device Specific Commands.

Dr. Moustafa Elshafei

 7-22

Figure 6-9
Universal commands must be implemented by all hart devices and provides
interoperability across the large base of products and manufactures. Universal commands
provide access to information that is useful in normal plant operation such as the instrument
manufactures, model, tag, serial number, descriptor, range, limits, and process variable.

Figure 6-10
Common practice commands access to functions which can be carried out by many
devices though not all, and device specific commands provide access to functions which can
be carried out by many devices.
Device Specific Commands provide access to functions which may be unique to a
particular device. Table xxx gives examples of these types of commands.
Device Description Language (DDL), a recent enhancement to the HART technology
extends interoperability to a higher level than provided through the Universal and Common
Practice Commands. As reflected in Figure 8, DDL provides a field device (slave) product
developer with the means to create a complete description of their instrument and all relevant
characteristics, such that it can talk to any host device using the language. This is analogous
to a printer driver in the personal computer world which enables an application to talk with a
printer such that what gets printed on the page is what was expected by the application.
Universal hand-held communicators capable of configuring any HART-based instrument
through DDL are available today. Broader application in other types of host systems is
expected. The HART Communication Foundation manages the centralized library of all

Dr. Moustafa Elshafei

 7-23
registered Device Descriptions and DDL is being supported by all members of the
Foundation.

7.6 MODBUS

MODBUS is a messaging structure, widely used to establish master-slave communication

between intelligent devices.

Since Modbus is just a messaging structure, it is independent of the underlying physical

layer. It is traditionally implemented using RS232, RS422, or RS485 over a variety of media
TP cables, and FOC.

The MODBUS protocol comes in 2 flavours:

ASCII transmission mode: Each eight-bit byte in a message is sent as 2 ASCII characters.
RTU (Remote Terminal Unit) transmission mode: Each eight-bit byte in a message is sent as
two four-bit hexadecimal characters.

The main advantage of the RTU mode is that it achieves higher throughput, while the ASCII
mode allows time intervals of up to 1 second to occur between characters without causing an
error.

The basic structure of a MODBUS frame is shown below:

[ADDRESS | FUNCTION |DATA | CHECKSUM]

The address field of a message frame contains two characters (ASCII) or eight bits (RTU).
Valid slave device addresses are in the range of 0 ... 247 decimal. The individual slave
devices are assigned addresses in the range of 1 ... 247. A master
addresses a slave by placing the slave address in the address field of the message. When the
slave sends its response, it places its own address in this address field of the response to let
the master know which slave is responding.

Dr. Moustafa Elshafei

 7-24
The function code field of a message frame contains two characters (ASCII) or eight bits
(RTU). Valid codes are in the range of 1 ... 255 decimal. When a message is sent from a
master to a slave device the function code field tells the slave what kind of
action to perform. Examples are to read the ON / OFF states of a group of discrete coils or
inputs; to read the data contents of a group of registers; to read the diagnostic status of the
slave; to write to designated coils or registers; or to allow loading, recording, or verifying the
program within the slave.

When the slave responds to the master, it uses the function code field to indicate either a
normal (error-free) response or that some kind of error occurred (called an exception
response). For a normal response, the slave simply echoes the original function
code. For an exception response, the slave returns a code that is equivalent to the original
function code with its most significant
bit set to a logic 1.

The data field is constructed using sets of two hexadecimal digits, in the range of 00 to FF
hexadecimal. These can be made from a pair of ASCII characters, or from one RTU
character, according to the network's serial transmission mode.

The data field of messages sent from a master to slave devices contains additional
information which the slave must use to take the action defined by the function code. This
can include items like discrete and register addresses, the quantity of items to be
handled, and the count of actual data bytes in the field.
If no error occurs, the data field of a response from a slave to a master contains the data
requested. If an error occurs, the field contains an exception code that the master application
can use to determine the next action to be taken.

The data field can be nonexistent (of zero length) in certain kinds of messages. For example,
in a request from a master device for a slave to respond with its communications event log
(function code 0B hexadecimal), the slave does not require any additional information. The
function code alone specifies the action.

Two kinds of checksum are used (LRC or CRC)for standard Modbus networks. The error
checking field contents depend upon the transmission method that is being used.

Dr. Moustafa Elshafei

 7-25
APPENDIX
SUMMARY AND COMPARISON OF FIELD BUSES
TRANSPORT MECHANISM

Communicatio Transmission Data Arbitration Error Diagnostics

n Methods Properties Transfer Method Checking
Size
PROFIBUS Master/Slave DP up to 12 244 Token HD4 Station, module &
DP/PA peer to peer Mbps PA bytes passing CRC channel diagnostics
31.25 kbps
INTERBUS-S Master/slave 500kBits/s, 512 None 16-bit Segment location
with total full duplex bytes, CRC of CRC error and
frame transfer h.s., cable break
unlimite
d block
DeviceNet Master/slave, 500 kbps, 8-byte Carrier- CRC Bus monitoring
multi-master, 250 kbps, variable Sonac check
others 125 kbps message Multiple
Access
ARCNET Peer to peer 31.25 K to 10 508 Token 16-Bit Built in
M bytes CRC
AS-I Master/slave Data and 31 Master/slave Manchest Slave fault, device
with cyclic power, EMI slaves with cyclic er Code, fault
polling resistant with 4 in polling hamming-
and 4 2, partly
out
Fieldbus Client/server 31.25 kbps 1 16.6 M Deterministic 16-bit Remote
Foundation publisher / Mbps 2.5 objects / centralized CRC diagnostics,
subscriber, Mbps device scheduler, network monitors,
Event multiple parameter status
notification backup
IEC/ISA SP50 Client/server 31.25 kbps 64 octets Scheduler, 16-bit Configurable on
Fieldbus Publisher / IS+1, 2.6, high & tokens, or CRC network
subscriber 5Mbps 256 low master management
priority
Seriplex Master / slave 200 Mbps 7680 / Sonal End of Cabling problem
peer to peer transfer multiplexing frame &
echo
check
World FIP Peer to peer 31.25kbps, 1 No limit, Central 16-bit Device message
& 2.5 Mbps, 6 variables arbitration CRC, time-out, redundant
Mbps fiber 128 data cabling
bytes “freshnes
s”
indicator
LonWorks Master/slave 1.25 Mbs full 228 Carrier 16-bit Database of CRC
peer to peer duplex bytes Sense, CRC errors and device
Multiple errors
Access
SDS Master/slave, 1 Mbps, 500 8-byte Carrier – CRC Bus monitoring,
peer to peer, kbps, 250 variable Sonac check Diagnostic slave
multi-case, kbps, 125 kbps message Multiple
multi-master Access

Dr. Moustafa Elshafei

 7-26

BACKGROUND INFORMATION

Technology Year Governing Openness

Developer Introduced Standard
PROFIBUS PTO DP-1994, DIN 19245 part Products from over 150
DP/PA PA-1995 ¾ vendors
INTERBUS-S Phoenix 1984 DIN 19258 Products from over 4000
Contact + manufacturers
DeviceNet Allen-Bradley March 1994 ISO 11898 & 6 chip vendors, 100+
11519 products
ARCNET Datapoint/SM 1975 ANSI 878 Chips, boards, ANSI
C docs
AS-I AS-I Fall 1993 Submitted to AS-II.C. Market item
Consortium IEC
Fieldbus Fieldbus 1995 ISO SP50/IEC Chips/software from
Foundation Foundation TC65 multiple vendors
IEC/ISA SP50 ISA & 1992-1996 IEC 1158/ Multiple chip vendors
Fieldbus Fieldbus F. ANSI 850
Seriplex APC, Inc. 1990 Seriplex spec Chips available multiple
interfaces
World FIP WorldFIP 1988 IEC 1158-2 Multiple chip vendors
LonWorks Echolon March 1991 ASHRAE of Public documentation on
Corp. BACnet protocol
SDS Honeywell Jan., 1994 Honeywell 6 chip vendors, 200+
Specification, products
Submitted to
IEC, ISO11989

Dr. Moustafa Elshafei

 7-27

PHYSICAL CHARACTERISTICS

Network Physical Media Max. Devices Max. Distance

Topology (nodes)
PROFIBUS Line, star & Twisted-pair or 127 nodes 24 Km (fiber)
DP/PA ring fiber
INTERBUS-S Segmented with Twisted-pair fiber, 256 nodes 400 m/segment,
“T” drops and slip-ring 12.8 Km total
DeviceNet Trunkline/ Twisted-pair for 64-nodes 500m
dropline with signal & power
branching
ARCNET Bus, multidrop, Twisted-pair coax 255 nodes 5 miles
staf fiber
AS-I Bus, ring, tree Two wire cable 31 slaves 100 meters, 300
star, of al with repeater
Fieldbus Multidrop with Twisted-pair 240/segment, 1900m @ 31.25 K
Foundation bus powered 65,000 500 m @ 2.5M
devices segments
IEC/ISA SP50 Star or bus Twisted-pair fiber, IS 3-7 1700m @ 31.25K
Fieldbus and radio Non IS 128 500M @ 5Mbps
Seriplex Tree, loop, ring, 4-wire shrolded 500+ devices 500+ ft
multi-drop, star cable
World FIP Bus Twisted-pair, fiber 256 nodes Up to 40 Km
LonWorks Bus, ring, loop, Twisted-pair, fiber, 32,000/ 2000m @ 78 kbps
star power line domain
SDS Trunkline/ Twisted-pair for 64 nodes, 126 500 m
Dropline signal & power addresses

SUMMARY
1. The main functions of an instrumentation system are: value and quality assessment, safety and
protection, control, and data collection.
2. Block diagrams help to view the subfunctions of each part of a process and determine its input and
its output, and how it is linked with the other parts of the process.
3. The main parts of a control loop are the process, the measurement, error detector, controller, and
control element.
4. P&I diagrams consist of graphical symbols and lines which illustrate the flow of a process and
identify the location and functions of its instruments, e.g. sensors, valves, recorders, indicators, and
instrument interconnections
5. An instrumentation system consists of four basic function parts; sensors, signal conditioning, signal
processing, and indicators.

CAN Bus I/O Characteristics

CANbus Signal Type Digital Interface
Output Voltage (High) VOH +4 volts min, +5.5 volts max
Output Voltage (Low) VOL +0 volts min, +1.5 volts max
Output Voltage +16 volts (Absolute Max)
Output Current 100mA

Dr. Moustafa Elshafei

 7-28
Impedance 124 ohm termination between +/- terminals
Circuit Type Differential
Bit Times 1uS @ 1Mb/s; 2uS @ .5Mb/s 4uS @ .25Mb/s
Encoding Format Non-Return-to-Zero (NRZ)
Transmit/Receive
1Mb/s @ 40 meters
Frequency
Topology Point-to-Point
Medium Shielded Twisted Pair (STP) @ 9 pin D-Sub
Carrier Sense, Multiple Access with Collision Detect
Access Control (CSMA/CD).
None destructive bit wise arbitration

Dr. Moustafa Elshafei

 7-29

References
Standards publications from Instrument Society of America
[1] S5.1-Instrumentation Symbols and IdentificationANSI/ISA-1984 (Reaffirmed 1992) 2ISBN: 0-87664-844-
8
[2] S5.2-Binary Logic Diagrams For Process Operations-ANSI/ISA-1976 (Reaffirmed 1992) ISBN: 0-87664-
331-4
[3] S5.3-Graphic Symbols for Distributed Control/Shared Display instrumentation, Logic, and Computer
Systems-1983 ISBN: 0-87664-707-7
[4] S5.4-Instirument Loop DiagramsANSI/ISA-1991, ISBN: 1-55617-227-3
[5] S5.5-Graphic Symbols for Process Displays-ANSI/ISA-1985, ISBN:0-87664-935-5

Other references
[6] M.R. Skrokov, Mini-and Microcomputer Control in Industrial Processes, Van Nostrand Reinhold Company,
1980.
[7] Curtis D. Johnson, Process Control Instrumentation Technology, 5th ed., Printice Hall, 1997.
[8] R. S. Figliola and D.E. Beasley, Theory and Design For Mechanical Measurements, 2nd ed. John Wiley &
Sonss, Inc, 1995.
[9] C. A. Smith and A.B. Corripio, Principles and Practice of Automatic Process Control, John Wiley & Sons,
Inc, 1985.
[10]John R. Bentley, Principles of Measurement Systems, 3rd ed. , Longman Group Limited, 1995.
[11]American National Standard, American National Standards Institute, New York.
[12]ASTM Standards, American Society for Testing and Materials, Philadelphia, PA.1-
[13]W.G.Andrew, Applied Instrumentation in the Process Industries, Vol.II, Gulf Publishing Company, 1974.
[14]John A. Hill, “10th Annual Control Market Outlook”, ISA InTech magazine, pp.36-42, January, 1997.
[15]W.G. Wilbauk,”50 Years of Progress in Measuring and Controlling Industrial Processes”, IEEE Control
Systems Magazine, pp. 62-65, 1996.

Further reading

IEEE 8023: Carrier Sense Access with Collision Detection.

IEEE-802-5: Token Ring Access Method. (www.ieee.org; IEEE, 445 Hoes Lane, Piscataway, NJ 08855-
1331)

Lawrence M. Thompson, Industrial Data Communications: Fundamentals and applications, ISA

Paul J. Fortier, Handbook of LAN Technology, 2nd edition, McGraw-Hill Publishing, ISBN 0-07-021625-8

Frank J. Derfler, Guide to Connectivity, 2nd edition, Ziff-Davis Press, ISBN 1-56276-047-5

Uyless Black, TCP/IP and Related protocols, McGraw-Hill Publishing, ISBN 0-07-005553-X

John E. McNamara , Technical Aspects of data Communication, Digital Press,

ISBN 1-55558-007-6

Daniel Capana, Fiber optics: the medium, Intech, ISA, April 1997.

Dr. Moustafa Elshafei

 7-30

Exercises

1. Define the industrial network CAN and discuss its essential characteristics.
2. Discuss ISO 11898 and ISO 11519 in conjuncture with CAN.
3. Situate CAN in the layers of the ISO reference model.
4. Explain the functions of the two layers of CAN.
5. Compare CAN and DeviceNet.
6. Elaborate on the features of DeviceNet.
7. What layers does DeviceNet specify?
8. Discuss in detail all the components of Foundation Fieldbus.
9. Discuss the three versions of the PROFIBUS family. Summarize the various differences.
10. What layers does HART implement in the ISO Reference model?
11. Define the following terms and indicate in what network are they used:
• Medium Access Control.
• Logical Link Control.
• Non-Destructive Bitwise Arbitration.
• Status field.
• Data field.
• Checksum.
• Universal Commands.
• Common Practice Commands.
• Device Specific Commands.

Dr. Moustafa Elshafei