Chapter 1

Introduction to Fieldbus Systems

In this chapter we will present an introduction to the Distributed Computer

Controlled Systems (DCCS) communications that are used to connect various industrial
systems, or what are known as FieldBuses.
First we will present the definition of the term Fieldbus. Second we will give brief
notes on the history of communication in industrial system and its development. Then we
will follow up to the evaluation stage of the fieldbus systems. After that we will
demonstrate the relationship between the fieldbus architecture and the reference OSI
network model. In addition we will numerate many types of Fieldbuses that exist in the
market for the time being. Doing this, we will describe each type and its standardization
information, and the CERN recommendation on them. Before we finalize, we will make a
comparison table to compare between the most famous five Fieldbuses types existing on
the market. At the end we will talk about the future trend of the fieldbus technology.

1.1. The Definition of a Fieldbus.

First we will define the fieldbus term and then we will go through its history in
brief in the next sections.
The augmented term Fieldbus is consisting of two terms, Field and Bus [Fieldbus
Introduction]. To start, the meaning of Field, as defined in industrial world, is a
geographical or contextual limited area. From the industry point of view the Field is an
abstraction of the plant levels. As for the term Bus is a well-known word in computer
science as a set of common line that electrically (or even optically) connects various units
(circuits) in order to transfer the data among them.

1
The origin of the fieldbus was to replace any point-to-point links between the field
devices (Field Devices are simply the Sensors and Actuators of the plant) and their
controllers (like PLC's, CNC's …etc.) by a digital single link on which all the
information is transmitted serially and multiplexed in time. We will see that the fieldbus
transfers, in most cases, this information in small-sized packets in serial manner.
Choosing the serial transmission has many merits in comparison with other kinds of
transmission like parallel transmission. For instance, the sequential or serial transmission
reduces the total required number of the connecting lines over greater distances than that
of the point-to-point or even parallel transmissions.
A set of rules must be defined in order to accomplish data transfer between the
units along the bus. This set of rules is called Communication Protocol or just the
Protocol. This is unlike the case of the ordinary point-to-point transmission where any
two connected entities send and receive data from each other whenever the data is
available. The protocol is responsible for two important rules on the bus, the mechanism
that any unit can acquire or seize the bus (from the network terminology this means the
way of Medium Access), and the synchronization between those multi-units on the bus.

The medium access protocol choosing is a vital (crucial) step in designing the
DCCS. This is because of the odd nature of the bursty traffic of such control systems. So
the existed LAN protocols such as the token ring or the CSMA1 are not appropriate for
the control applications. For the token ring case, the more nodes you add, the longer the
time each node will wait till it can transmit its data. Needless to say that the CSMA
protocols, which are contention based protocols, will add randomness to the overall
Response Time2 of the node data (we will explain in chapter 4 the response time in more
detail). This came from the way that the CSMA allow only one node to transmit data if
and only if no other node is seizing the medium. The randomness occurs when a

1
Carrier Sense Multiple Access.
2
Response time is the elapsed time interval between sending the data from producer node, and the
receiving of that data at the consumer node.

2
collision3 happens as the nodes which encountered the collision will have to wait to for a
random time before it start again transmitting. A number of solutions have been proposed
to extend the CSMA in order to enhance its performance. For example, the collision
avoiding, collision detection, and collision resolution are all extensions to the CSMA
protocol. None of these solutions can fit directly for the control network applications; in
fact they need some other modifications like the CAN fieldbus protocol [Raji 94].

In general and from our point of view, there are three main issues that must be
considered when designing the any DCCS, which are:
1- The communication protocol used.
2- The interoperability of the units.
3- The topology of the network used.
We have talked about the communication protocol and its two important sub-
issues. Now we will talk about the topology of the network used. Although almost any
type of topology that is used with the ordinary LAN can be fit with the fieldbus system
requirements, but there are two other factors that affect the selection of such topology.
These factors are the medium access method used and the medium used in the DCCS
(twisted pair, coaxial cables, optical fibers … etc.). Other more specific factors are used
to select the topology; like the cost of wiring installation and the network fault tolerance
[Raji 94]. The overall performance, reliability, and ease of installation beside the total
cost are affected by the topology, medium access scheme, and type of medium used.

1.1.1. Why Define a Bus?

There are two main reasons in favoring the fieldbus to the old point-to-point
method in connecting the devices along the factory. These reasons are:
- The data transmission is done in standard form to suit the special demands of the factory
communications.

3
Collision is when two or more nodes try to transmit at the same time on the network.

3
- The data exchange along the bus is available easily to all the nodes at the same time (i.e.
no need for extra cable to connect certain node to another one).
The advantages of using a fieldbus in comparison to the point-to-point method are
many but here we will list some of the most general advantages:
• The ability to connect new units on the bus becomes more flexible. This means
that the network extension also becomes easier to achieve.
• The distances that can be covered by the fieldbus are greater than that of the old
point-to-point system as we mention before.
• Substantial reduction of wiring.
• A great reduction of the total costs.
• The installation and operation of the fieldbus and their associative devices
become easier.
• Possibility to connect products from different manufacturers. This is known as
the interoperability of the fieldbus.
In addition to these advantages, there stand a fewer number of demerits that we will
state now:
• There is a need to better knowing how the fieldbus system works, and what type
of fieldbus is more appropriate for your application.
• The investment in both equipment and tools rises higher. For example the
monitoring tools.
• In some cases the interoperability remains non-assured although there may be
claims that all the equipments are compatible.
• Higher initial costs as each node must have communication equipments for
transmitting and receiving the data.

After we have just discussed the Fieldbus notation and definition we will now
describe in some details the origin of the fieldbus.

4
1.2. An Introduction to Industrial Systems Communications.

In general the industry can be divided in two categories; which are the Process,
and the Manufacturing [Almeida 99-1].
The process industry, deals with processes, continuous, or discontinuous, which
have very large material flows and often have strict safety requirements (e.g. power
generation, cement kilns, petrochemical production). While the manufacturing industry,
is concerned with the production of discrete objects. Achieving the maximum throughput
of produced goods is, normally, very important aspect in the industrial systems.
The industrial systems faced the needs to enhancement in production monitoring
and quality control and in the same time maintaining the costs of all this as low as
possible. This happened in the last few decades due to growing social needs, which in
turn enforce the industrial systems to grow to match up with these needs.
So any operation that runs manually had to be replaced with a faster, and more
reliable automated operation. This also provides both the factories and the plants with
necessary monitoring which they both sought for better supervisory and quality control.
Introducing all this number of automated unites into the factories needed an efficient
method to connect them together, to communicates with each other, and to transfer the
various supervisory data to the monitors. This leads to the introduction of the
communications networks into the factories.
We now will present two subsections that briefly describe the history of
communications development in the industrial processes.

1.2.1. Process Industry Communications: a Historical background

The process industry communications developed in the last four decades in four
main steps. Each step introduced a nearer control to the field devices or more distribution
of the many tasks of the control and/or supervisory. The first step was a star topology that
connects the Field Devices (FD's) into single mainframe computer in the control room.
This mainframe computer had to make all the control and supervisory tasks. To

5
accomplish these tasks, the mainframe had to transfer the required data from and to the
field devices using the traditional point-to-point methodology. To see an example of this
configuration see Fig. 1.1. This configuration called the Centralized configuration. This
same configuration was famous at the 60's of the last century.

Fig. 1.1. Star topology typically used in the architecture of Process Control
Systems up to the 1960s.

There are several disadvantages associated with such a centralized architecture system we
listed below:
1- The complexity of the wiring was so high and difficult to be re-installed, and above
this they were expensive.
2- The high cost of the mainframes that are doing the control tasks were also important
issue.
3- The mainframe failure represented a much higher risk to the system as it can lead
toward the collapsing of the whole system.
4- The lack of standards leads to the impossibility of interchanging some elements with
faster or more reliable ones.

6
 The second step of the process industry communications development was the
division of the supervisory and the control tasks into two or more controllers. Each
controller now has its own field devices that attached to it using the old point-to-point
way. Fig. 1.2. to see the example of this configuration which was known as the
Hierarchal Architecture.
In turn, and as we see from the figure these controllers are attached to one computer
called the management information system. These controllers were placed in the same old
control room with the management information system computer. The period which
witnessed the prosperity of such architecture was the early the 70's of the twenty century.
One thing is sure that is the fault tolerance now become easier with this hierarchy.

Fig. 1.2. The hierarchical architecture which was popular in Process Control
Systems during the early 1970s.

The great revolution of the Integrated circuits (IC's) made the next third step of
the process industry communications became true. This revolution made it possible for
more distribution of the tasks. What is more the performance got better and the total cost
reduced a lot. Now the controllers communicated with each other via serial digital

7
network. Furthermore the controllers were placed nearer to the field devices which
reduced the complexity and the costs of wirings, as the length of the cables are shortened.
This happened during the mid of the 70's of the last century. Unfortunately, the field
devices are still point-to-point wired to the controllers. These controllers are called the
local controllers to differentiate between them and the other controllers that might be in
the control room. Also, the control room contains now two independent units; one is the
Operator Consol, and the other is the Supervisory Computer. These two units are attached
to each other via the same serial digital network that allows them to communicate with
local controllers.

Fig. 1.3. A first approach towards a distributed architecture introduced in Process

Control Systems after the mid 1970s.

As an example of the first distributed system of this kind for process control was the
(TDC 2000 system) introduced in 1975 by Honeywell.

The semi-final stage of the industrial process took place in the early 1980's. By
then the number of field devices has growing incredibly. This made the system designers

8
to connect these devices via serial digital network. Refer to Fig. 1.4. as it shows an
example of this modern architecture. The introduction of digital network simplified the
cabling and wirings of the system leading to ease of maintenance. The network that
connects these field devices called FieldBus. We have already talked about the fieldbus
definition early in this chapter.

Fig. 1.4. The fully distributed architecture, based on a fieldbus, found in

modern industrial automation systems.

1.2.2. Manufacturing industry: a Historical background

After we talked about the process industry and its communications, we now move
to the second category of the Industry that is the Manufacturing industry and its relevant
communications.
The manufacturing industry and its communications developed significantly in the
last four decades along with the process industry. The development of both was
motivated by the need of lower production cost while maintaining high performance and

9
good quality control. From the 50's to the early 70's of the last twentieth century the
manufacturing plants were consisted of many isolated production units which called cells.
During this period the automation development was limited to these cells only as
independent islands. By the mid 70's of the last century, the need to improve the
production monitoring and the miscellaneous control functions leaded the way to connect
the production islands with each other. This means that the manufacturing industry like
the process industry directed towards the distributed architecture. Fig.1.5. shows the trend
towards the distributed architecture in the manufacturing industry. What is more, Fig. 1.6.
shows the fully modern distributed manufacturing architecture. This hierarchy also is
known as the Computer Integrated Manufacturing (CIM). We will present the definition
of the term CIM shortly in this section.
The CIM defined at least three levels of interconnection as depicted in Fig.1.6. Those
levels are:
• Factory Level (Level 2): this level is responsible to connect the different areas
within the factory, (e.g. management, product development, maintenance, etc.)
• Cell Level (Level 1): in this level we are connecting various automation
equipments at the factory floor4 (Robot Controllers, PLCs5, CNCs6, … etc.).
• Sensor/Actuator Level (Level 0): in this level we are to link sensors and
actuators to the controllers that are found in level 1.

4
This is also known as Reflex Automata.
5
Programmable Logic Controllers.
6
Computerized Numerical Controls.

10
Fig. 1.5. The trend towards the use of a distributed architecture in manufacturing
industry to interconnect cells across the plant.

Fig. 1.6. The Computer Integrated Manufacturing (CIM) Architecture.

11
 Like the process industry, the cabling and wirings problems faced the
interconnection of the manufacturing industry layers. Many numbers of solutions were
presented to resolve these problems all were based on the serial digital networks, which at
this time were famous. They start with a general purpose LAN networks at level 2. This
solution did fit with the networks in both level 1 and level 0. These levels required special
communication requisites. For example at those levels the data transfer rate is rather high
and its packets are small. This can not accommodated by the of-shelf traditional LAN's.
From all what we just mentioned the need to invent new special networks aroused to
connect level 1, and finally level 0, at the same time . Those new networks were called
FieldBuses.
We needed a new architecture that combines all this communication protocols.
This new hierarchy is called the CIM or Computer Integrated Manufacturing architecture
and can be seen in Fig.1.6. This architecture organizes the level of factory
communication systems and was initially derived from the MAP or the Manufacturing
Automation Protocol project. This project was initiated by North American industrial
companies that leaded by General Motors (GM) at 1980. The main target of this group is
to define a new open standard for the communications in the factory that can allow the
interoperability (compatibility) between many components that came from different
manufacturers. There had been similar groups and attempts to standardize such protocols
in Europe during the 80's of the last century. For examples, the FIP existed in France,
Profibus in Germany, and P-NET in Denmark. Later in this chapter we will show again
these European standards and their details.
At the next subsections we will give a brief introduction to three types of the
fieldbus protocols namely the WorldFIP, the PROFIBUS, and the CAN. These three
protocols are the recommended by the CERN.
Although both Process and Manufacturing Industries communications have
developed separately from each other, due to their differences in definition terms.
However and at the end those differences tend to disappear. In fact the good market
inspector would see that both Industries use now the same electronic systems in

12
implementing their miscellaneous functions, such as the closed loop control, the
networking functions, and the operator/machine interface.

At the end we would like to add that the fieldbuses play a major role in the
modern industry automation development. This is not everything, but it takes a prominent
place in interconnecting advanced real-time distributed systems that are used in avionics,
data acquisition, and the modern automotive applications.
The fieldbus wide-area of application increased the pressure to define a new
standard from the user end side. This will allow more compatibility among different
equipment vendors, leading to more reduction in costs and more and more improvement
in performance. In addition to all this, it will give the user more freedom in choosing the
appropriate fieldbus protocol that best matches his needs without changing the whole
automation system hierarchy.

Fig.1.7. summarizes the difference between the old point-to-point hierarchy and
the fieldbus hierarchy [Fieldbus Introduction]. Again we put this figure in order to fully
differentiate between these two systems, and to serve as an end to this section.

13
 Fig. 1.7. Comparison between the point-to-point and the fieldbus Hierarchies.

1.3. The FieldBuses and the Network Reference Model.

In the previous sections we have discussed fieldbus definition and its historical
origins. We mentioned that it is considered as a network that connects the field devices at
the factory floor together with the controllers. Since it is a network, we have to know its
relation with the famous OSI7 reference model. We will describe the fieldbus in terms of
the layers of the OSI model.
To start we will take the definition of the OSI model from [Tanenbaum 96] who
said "The OSI model organizes the protocols used and the services provided by a general
communication system in a stack of layers". In other words, the OSI is complete layered

7
Open System Interconnected proposed by ISO.

14
network model in which each layer does certain communication service. One can see in
Fig. 1.8-a. the reference OSI model layers and its layers.
How it works? From the figure we can see that if a node wants to send a data packet
from the application it must first call for the sending service of its application layer which
in turn will call the sending functions in the next layer, and so on till the data is sent at the
physical medium to the other node. This node will reverse the sequence till the received
data reaches the application layer of its node then to the application which will used this
data.

We will now list below the seven layers of the OSI model with their functions: -
1- Application layer is to provide the services that are required by specific
applications.
2- Presentation layer is responsible for the data interpretation, which allows for
interoperability among different equipments.
3- Session layer is concerned with any execution of remote actions.
4- Transport layer is responsible for the end-to-end communication control.
5- Network layer is concerned with logical addressing process of nodes and
routing schemes.
6- Datalink layer is responsible for the access to the communication medium,
and for the logical transfer of the data.
7- Physical layer is concerned with the way that the communication is done
physically.

Any communication system that is based on the OSI seven layers will have both
merits of higher flexibility and compatibility with products from different vendors.
Nevertheless, the same OSI system (due to its complexity) has a considerable overhead
in both, the communications, and the processing.

15
 Modification to the MAP project was necessary as the node implementation
become more complex in order to support all the services of the OSI reference model
[Almeida 99-1]. The modification allowed the short length control data packets, which
occurs at high rates, to be directly transmitted through the application layer to the
datalink layer. Which means that we abbreviated the OSI hierarchy into 3-layer model as
can be seen in Fig.1.8-b. The resulting fieldbus is referred to as a 3-layered Architecture.
These layers are: the Application layer, the Datalink layer, the Physical layer.
One may assume that the other four layers of the OSI model that are not available
in the fieldbus hierarchy have disappeared along with their own functions and services
[Almeida 99-1]. This is absolutely wrong, as these functions are augmented into the
existed layers. For example, the main function of the presentation layer, which is to
support the interoperability between different equipments, is done now by the application
layer in the fieldbus. What is more, the assembling and disassembling of data packets
which was the function of the transport layer is done now by the datalink layer in the
fieldbus network. If routers to be used in some fieldbus networks, then the routing
service, which was assigned to the network layer, is done by the application layer in
most cases in the fieldbus.

Fig. 1.8. The OSI 7-layers reference model (a), and the reduced fieldbus
3-layer structure (b).

16
 There exist many protocols and services that are laid in the 3-layerd hierarchy of
the fieldbus network. This at the end will lead to a great difficulty in evaluating one and
unique international fieldbus standard. In fact there are many different fieldbus protocols
in the world. There are large differences that can be found in the three layers of any
fieldbus protocol and their similar layers in another fieldbus protocol. The designer of the
DCCS communications system has multi-option solutions to fulfill his system
requirements. These requirements are varied from one situation to another. In most cases
the quality of services and the system throughput in addition to the overall system
performance are all a common requirements any nearly all the DCCS systems. Also a fast
response time is usually required by the real-time computer controlled networks
designers.

Now we will go through the different types of the fieldbuses that do exist in the
international market and their national origins and standards.

1.4. Different Types of Fieldbuses.

As we seen before, the fieldbus technology started at the early beginnings of the
80's of the previous century in many countries on the national level. For examples, in
France; the Factory Instrumentation Protocol (FIP), in Germany both; the Controller Area
Network (CAN), and the Process Field Bus (PROFIBUS), and in Denmark; the Process
Network (P-NET) protocol, are all appeared in the same time period at the beginning of
the 1980's [Tovar 99-2].
The standardization efforts started at the same time and on the international level
at the International Electro-technical Commission (IEC). Several new architectures were
proposed on exiting old products. For examples, the MIL 1553B (Haverty, 1986), HART
(Rosemount, 1991) or BITBUS (Intel, 1984) were all either products or at least
prototypes. At this stage some other protocols were plain proposals on papers only like

17
the FIP and PROFIBUS. Therefore, until the end of the 80’s no progress was achieved at
this level. In fact, only in 1993 the first international standard has been agreed: the
physical layer with the following model information (IEC 1158-2, 1993).
At the national and regional levels, the standardization has made more progress
than that of the international level. For examples, the P-NET is a Danish national
standard since 1990 (DS 21906, 1990), PROFIBUS is a German standard since 1990
(DIN 19245, 1990), and FIP (later re-named as WorldFIP) is a French standard since
1989 (NF C46, 1989). Each protocol has addressed different technical options.
As a consequence of the difficulty to achieve a truly international fieldbus
standard, in 1995 the CENELEC (European Committee for Electrotechnical
Standardization) proposed an intermediate European standard, comprising the three
national standards existing in Europe: P-NET, PROFIBUS and WorldFIP. This
initiative led, in 1996, to the standard number EN 50170. Although this European
standard is a set of non-compatible profiles, it simplifies the choice of fieldbuses in
Europe, from several tens of fieldbus options down to three [Tovar 99-2].
An additional proposal is being considered as a forth profile within the EN 50170:
the Fieldbus Foundation. Fieldbus Foundation was formed in late 1994 from a merger of
WorldFIP North America and the Interoperable Systems Project. In 1996, Fieldbus
Foundation introduced its own specification (BSI DD 238, 1996), which is now being
considered for the EN 50170.
Other committees within international standardization bodies have been working
to define other LAN technologies for specific application domains. Within ISO
(International Organization for Standardization) and IEC, there are some of the more
relevant like: ISO TC72, for the Textile Industry, ISO/IEC-JTC1 SC25, for the Home
Automation, IEC TC9, for the Trains, ISO TC8, for the Ships and Shipbuilding, ISO
TC67, for the Mineral and oil Industries, and ISO TC82, for Mining Industry only. At
the European level, some of the more relevant are CEN TC247 of the Building
Automation applications and CEN TC251 which dedicated for Medical Domain and
Hospitals.

18
 Still, until this moment lots of different Fieldbus protocols are being developed
and sold out. Some are also being standardized at the international level. For instance,
Interbus-S (DIN 19258, 1995) and Actuator to Sensor Interface or ASI (ASI, 1996),
among others, are being considered as new standards like the EN 50254 for the high
efficiency communications subsystems for small data packages. Also being considered is
the PROFIBUS-PA (DIN 19245-4, 1996) and the Device WorldFIP (NF C46-638,
1996) simplified variants of PROFIBUS and WorldFIP, respectively. For instance, ASI
does only aim to inter-connect boolean-state devices and its frame only supports a
reduced number of data bits.
Other trials have experienced a different direction in evolution. Take the CAN
(Controller Area Network) which is a success story. It was originally designed for use
within road vehicles to solve cabling problems arising from the growing use of
microprocessor-based components in vehicles. CAN was standardized by ISO (ISO
11898, 1993) has a "Road Vehicle - Interchange of Digital Information" system and
since then it is a standard for the automotive applications, a domain area where VAN
(ISO 11519, 1995) is a small contender of the CAN. Due to its very interesting
characteristics, CAN is also being considered for the automated manufacturing and
distributed process control environments, and is being used as the communication
interface with other architectures, such as DeviceNet [Tovar 99-2].

In the next section we will concentrate on the CERN fieldbus protocols

recommendations and we will spot on these protocols in brief.

19
1.5. CERN Recommendations on Fieldbuses.

CERN is the European Organization for Nuclear Research (the term CERN is the
English translation to the same name but in French) that was established in 1954 to
mainly serve the research of physics. But with the time passed the CERN became more
interested in other aspects that may have some relationship with the physics. For
example, the CERN involved in computer networking as the World Wide Web (WWW)
was first developed at CERN in the beginnings of the 1990's [CERN 97].
Now that CERN is engaged in a large scale project of LHC experiments where
fieldbuses is used to control and monitor the equipments of these LHC experiments, it
was necessary for the CERN to create a working group on Fieldbuses on control at the
end of 1995. This working group main task is to investigate the appropriate fieldbus
type(s) that can fit to LHC experiments. The working group finally found out that
recommending one fieldbus may not satisfy all the users, so instead they had
recommended three Fieldbuses. These are:
1- Controller Area Network (CAN).
2- Process Field Bus (PROFIBUS).
3- World Factory Instrumentation Protocol (WorldFIP).

The recommendation was taken after the working group had leaded intensive
investigation procedures to the various Fieldbuses that are available at the international
market [CERN 97]. The working group took into account the technical requirements of
the experiments which are: Open system, Industry standard, Wide Range of product
availability, Cheap Connections, Capacity of reliable remote hardware resets, robustness.
These are not all the points; in fact they addressed some extra technical points such as:
Determinism, Bus mastership, Redundancy, Coverage, Throughput, Bandwidth, and the
Galvanic Isolation; not to mention the cost considerations. For more information see
[CERN 97], or refer to the CERN web page at: WWW.CERN.ORG.

20
 Next we will give a brief description to these three protocols.

1.5.1. Controller Area Network (CAN):

The CAN protocol is a priority-based bus network using a Carrier Sense Multiple
Access with Collision Avoidance (CSMA/CA) medium access scheme. In this protocol
any station can access the bus whenever it becomes idle. However, unlike to the Ethernet
networks, the collision resolution is non-destructive, which means that one of the
messages being transmitted will succeed. The collision resolution mechanism is very
simple and is supported by the frame structure, or more specifically by its twelve leading
bits, denoted as start bit and identifier fields. This identifier field serves for two different
purposes. On one hand it is used to identify any message stream in a CAN network. Take
for example a sequence of messages concerning the remote reading of a specific process
variable. On the other hand, it is a priority field, which enables the collision resolution
mechanism to schedule the contending messages.
This collision resolution mechanism in CAN works as follows:
when the bus becomes idle, every station with pending messages will start to transmit.
Due to its open-collector nature, the CAN bus acts as a big AND-gate, where each station
is able to read the bus status. During the transmission of the identifier field, if a station is
transmitting a "1" and reads a "0", it means that there was a collision with at least one
higher-priority message, and this station aborts the message transmission at once. Thus
the highest-priority message being transmitted will proceed without encountering any
collision, and thus will be successfully transmitted to its destination. Obviously, each
message stream must be uniquely identified.
The collision resolution mechanism that is used by the CAN protocol imposes
strict limitations to the bus length and its transmission data rate. For example, considering
a bus length of 40m, the maximum data rate is 1Mbps. The longer buses are possible but
at the cost of a data rate reduction [Tovar 99-2].
For more information about the CAN protocol see [Tindell 94], [Wellings 95],
and [Tovar 99-2].

21
1.5.2. Process Field Bus (PROFIBUS):

The PROFIBUS protocol is based on a token passing procedure used by master

stations to grant the bus access to each other, and a master-slave procedure used by
master stations to communicate with slave stations. The PROFIBUS token passing
procedure uses a simplified version of the Timed-token protocol. The medium access
functions which are implemented at the layer-2 of the OSI reference model, is called
Fieldbus Data Link (FDL). In addition to controlling the bus access and the token cycle
time, the FDL is also responsible for the provision of data transmission services for the
application layer.
PROFIBUS supports four data transmission services which are: Send Data with
No-Acknowledge (SDN); Send Data with Acknowledge (SDA); Request Data with Reply
(RDR) and Send and Request Data (SRD). The SDN is an unacknowledged service used
for broadcasts from a master station to all other stations on the bus. An important
characteristic of other services is that they are immediately answered, with a response or
an acknowledgement. This feature, also called "immediate-response", is particularly
important for the real-time bus operation.
In addition to these services, industrial applications sometimes require the use of
periodical transmission methods. A FDL-controlled polling method (i.e. cyclical polling)
may be used to scan field devices, such as sensors or actuators. PROFIBUS enables a poll
list to be created at the FDL layer, allowing the execution of cyclical polling services
based on RDR and SDR services.
For more information please refer to [Tovar 99-2], and table 1.1.

1.5.3. World Factory Instrumentation Protocol (WorldFIP):

A WorldFIP network interconnects stations with two types; either a bus

arbitration station or production/consumption stations. At any given time instant, only
one station can be the bus arbitration station. Hence, in WorldFIP, the medium access

22
control is centralized, and performed by the active bus arbitrator or what is known as the
BA.
WorldFIP supports two basic types of transmission services: exchange of
identified variables and exchange of messages. In this sub-section we will address the
exchange of identified variables only, since they are the basis of the WorldFIP real-time
services. The exchange of messages is used to support manufacturing message services.
In WorldFIP, the exchange of identified variables is based on a Producer/Consumer
model, which relates producers and consumers within a distributed system. In this model,
for each process variable there is only one producer, and one or several consumers. For
instance, consider the variable associated with a process sensor. The station that provides
the variable value will act as the variable producer and its value will be provided to all the
consumers of the variable (e.g., the station that acts as process controller for that process
variable, the station that is responsible for building an historical database, or even a
supervisory node that monitors this variable value).
In order to manage any transactions associated with a single variable, a unique
identifier is associated with each variable. The WorldFIP Data Link Layer (DLL) is made
up of a set of produced and consumed buffers, which can be locally accessed (through
application layer services) or remotely accessed through network services. In WorldFIP
networks, the bus arbitrator table (BAT) regulates the scheduling of all buffer transfers.
There are two types of buffer transfers that can be considered in WorldFIP. These are:
periodic and aperiodic (sporadic). The BAT imposes the schedule of the periodic buffer
transfers, and also regulates the aperiodic buffer transfers in the times that there are no
periodic buffer transactions.

We will leave other details of this protocol to the next chapter as the WorldFIP is
the protocol that will be considered in this thesis.

23
 1.6. Comparison between different types of FieldBuses: -

Many references had made comparisons between different types of Fieldbuses, in

which they include many aspects to differentiate between these Fieldbuses. We here
summarize the differences between the most famous five types of Fieldbuses as we see
them and but them in Table 1.1. [Raji 94].

Fieldbus
BACnet ISP CAN CEBus WorldFIP
Comparison
Automotive
Building Process Household Process
Application Target Automation Control
Textile,
Devices Control
Production Line

OSI Layers 1, 2, 3, 7 1, 2, 7 1, 2 1, 2, 3, 7 1, 2, 7

Command Based
or Both Status Command Command Both
Status Based

Bus or Net Net Bus Bus Net Bus

Communication Central
Master-Slave --- Peer-to-Peer Peer-to-Peer
method Arbitration

Media access CSMA/CD, Master-Slave

Token-Passing
CSMA/CR CSMA/CA Peer-to-Peer
algorithm Token bus

RF, Power-
Coax, Fiber,
Media supported TP
TP Fiber, TP, Coax Line, Coax, TP, Fiber
TP
Addressing
Schemes: Broadcast
All All All Broadcast
(Uni- Multi- Multicast
broadcast)

24
 Standard
Maximum data 2.5Mbps, 5M
2.5 M 10 M 2M 2.5 M
rate [up to 20Mbps
theoretically]

Power from
NO YES NO NO YES
Network?

240 (32 per

Max no. of nodes 255 8128 2 ^ 48
segment)
256

Priority8 NO YES YES YES YES

Chip, Chipset? YES NO NO YES YES

Network
YES YES NO NO YES
management tools?
Connectivity Repeater and
(repeater, non-standard --- --- Repeater ---
bridge, router, Gateway
gateway)

Table 1. 1. Comparison between Different types of Fieldbuses.

BACnet: Building Automation Control net.

CAN: Control Area Network.
WorldFIP: World Factory Instrumentation Protocol.
ISP: Interoperable Systems Project.
CSMA: Carrier Sense Multiple Access.
CR: Collision Resolution.
CA: Collision Avoidance.
CD: Collision Detection.

8
Here, priority indicates whether the fieldbus supports priority level of command or network message.

25
RF: Radio Frequency.
TP: Twisted Pair (cable).
Coax: Coaxial Cable.

In table 1.1. the term peer-to-peer means that any node can talk with each other on
the net, as long as set one of them as a master and others as slaves, the communication
method turns into Master-slave. Therefore, peer-to-peer in the table indicates that the
fieldbus can use both common methods. In fact the master-slave is actually a subset of
peer-to-peer method.
What is more, the terms Command-based and the Status-based are related to the
way the fieldbus use to sends and receives the information along the network. Here is an
example of "Traditional Mail" and "TV Broadcasting" to compare Command-based
and Status-based. In traditional mail, the sender needs to send three letters if he wants to
contact those three ones. Each letter must be marked with different destinations
(receivers). "Command-based" fieldbus sends three messages to three different nodes. In
the "TV broadcasting", the sender broadcasts the message; those three receivers will pick
the message to them, while others ignore this message. "Status-based" fieldbus also sends
one message to the whole net. Only the nodes relating to this message pick it up.

26
1.7. The Future of the Fieldbus systems:

Like all other technological products Fieldbus is up to continuing process of

updating. We noticed that further developments are going on in the fieldbus technology
especially in the vehicle systems. A new era has been born which some specialists called
the "X-by-wire". This technology tends to replace all the mechanical linkages that are
found in the vehicles with digital links and wire all these links into one network protocol
that entirely runs the vehicle. Rising now in the horizon of this era are two protocols. The
first is called FlexRay, and the second is called TTP. These two are based on the older
kin; the CAN. Among the anticipated benefits: better fuel economy, better vehicle
performance in adverse conditions, and advances in safety features such as collision
warning and even automatic collision avoidance systems. Fig. 1.9. shows one of the
configuration topologies of the FlexRay protocol which called the active star.

Fig. 1.9. FlexRay Active Star Topology.

27
 We mentioned that these new protocols are based on the older CAN, why? These
protocols try to resolve problems encountered when designing the new X-by-wire
automobiles using the old CAN protocol.
These problems arise from the arbitration method that is used to divide the bus
between the competing messages. The CAN used a priority scheme to assign the highest
priority to the oldest queued message regardless of the transmitter making the attempt.
FlexRay is a hybrid protocol that allocates portions of network time to both a time-
triggered protocol and to prioritized message access. While the CAN prioritization
scheme is based on dominant and recessive bit-values, FlexRay uses timing offset values
proportional to priority. As its name suggests, FlexRay adds flexibility—permitting
coexistence of both prioritized and time-triggered messages on the same network. There
are other proposed protocols such as TTP (Time-Triggered Protocol), FTT-CAN
(Flexible Time-Triggered Communication on CAN), and TCN which is Train
Communication Network.
For more information about these new state-of-the-art protocols, please refer to
[Ferreira 2002], and [Koopman 2002].

In the next chapter we will introduce the WorldFIP protocol and standard in
details.

28