The Fieldbus War: History or Short

Break Between Battles?

Abstract: Understanding the structure of fieldbus standards
means knowing their history. This paper reviews the evolution of
international fieldbus standards in the area of industrial automation
and demonstrates how the pre-sent situation of the IEC 61158
standard with its 18 different fieldbus systems came about. While
the fieldbus standards seem to have reached a stable state, the up-
coming application of Ethernet in the field of automation might create
a similar conflict potential. We discuss the current status of
Industrial Ethernet and the related standardization efforts.

1. Introduction
The history of fieldbus systems did not start in the mid 1980s,
in fact the roots of industrial networks are much older and date
back to the early 1970s [1,2]. How-ever, it was only during the 1980s
that fieldbus systems started booming. As different as the various
application areas were the approaches invented, and from today’s
point of view it seems that creating new fieldbus systems was a
trendy and fashionable occupation for many com-panies in the
automation business. The overwhelming number of different
systems appalled rather than attract-ed the customers, and what
followed was a fierce selec-tion process where not always the
fittest survived, but often those with the highest marketing power
behind them. Consequently, most of the newly developed sys-
tems vanished or remained restricted to small niches.
Nevertheless, also the big companies soon realised that proprietary
fieldbus systems will always have only lim-ited success and that
more benefit lies in making the specifications publicly available,
so that different ven-dors may produce compatible devices,
which gives the customer back their freedom of choice [3,4,5,6].
Finally, it was this openness that paved the way for the break-
through of fieldbus systems. From creating an “open” specification to
the standard-isation of a fieldbus system it is only a small step.
The basic idea behind it is that a standard establishes a speci-fication
in a very rigid and formal way, ruling out the possibility of
quick changes. This attaches a notion of reliability and stability to
the specification, which in turn secures the trust of the customers and,
consequently, also the market position. Furthermore, in many
countries standards have a legally binding position, which means
that when a standard can be applied (e.g., in connection with a
public tender), it has to be applied. Hence a standardised system
gains a competitive edge over its non-standardised rivals. It is
therefore no wonder that after the race for fieldbus
developments, a race for standardisation was launched. Now this
was quite easy on a national level, and most of today’s relevant
fieldbus systems soon became national standards. Troubles start-ed
when international solutions were sought. This caused heavy
turbulences and opened a battlefield for politics that gradually
left the ground of technical discussion. Table 1 shows the timeline
of these “fieldbus wars”

2. The German-French fieldbus war

In the second half of the 1980s, at the beginning of the IEC
efforts in the technical committee TC65C, the development of
fieldbus systems was mainly a European endeavor, thrust forward
by research projects that had still a strongly academic
background as well as many proprietary developments. The most
promising results were the French FIP and the German PROFIBUS.
Both were soon standardized on the respective national level and
finally proposed to the IEC for international stand-ardization.
Unfortunately, the approaches of the two systems were
completely different. PROFIBUS was based on a distributed
control idea and in its original form supported an object-oriented
vertical communica-tion according to the client-server model in
the spirit of the MAP/MMS specification. FIP, on the other
hand, was designed with a central, but strictly real-time capa-ble
control scheme and with the newly developed pro-ducer-consumer
(producer-distributor-consumer) model for horizontal
communication. Different as they were, the two systems were
suited for complementary application areas. Evidently, a uni-
versal fieldbus had to combine the benefits of both, and an expert
group came up with a new proposal [7]. In an extension of FIP
towards WorldFIP, the functionality of the client-server model was
added. On the other side, the ISP (Interoperable System Project)
attempted to demon-strate how PROFIBUS could be enhanced with
the pub-lisher-subscriber communication model which is about the
same as the producer-consumer model of FIP. Strange enough,
the ISP was abandoned in 1994 before reaching a mature state
because of strategic reasons [8]. In the meantime, the leading role
in the standardisa-tion efforts on IEC level had been taken not by the
Euro-peans, but by the work of the committee SP 50 of the
Instrumentation, Systems and Automation Society (ISA), who had
been much more efficient during the late 1980s and exerted an
important influence on the layer structure of the standard as we
have it today [9,10]. Still, by the mid 1990s, the IEC committee
had not produced any substantial outcome for more than eight
years. The only exception was the definition of the Physical
Layer, which was adopted as IEC 61158-2 standard already in
1993. This part is the one that has since been used very successfully
mainly in the process automation area. On top of the physical
layer, however, the standardization drafts became more and more
comprehensive and over-loaded with all kinds of communication
and control principles imported from the different systems. In the
Data Link Layer specification, for example, three differ-ent types of
tokens were introduced: The “scheduler token” determines which
station controls the timing on the bus, with the “delegated token”
another station can temporarily gain control over the bus, and the
“circulated token” is being passed from station to station for bus
access. The problem with these all-inclusive approaches was that a
full implementation of the standard was too expensive, whereas a
partial implementation would have resulted in incompatible and not
interoperable devices (a problem which was encountered also in the
early imple-mentations of, e.g., PROFIBUS-FMS, where
significant parts of the standard are optional and not mandatory).

3. The international fieldbus war

In 1995, after long years of struggles between Ger-man and
French experts to combine the FIP and PROFIBUS approaches,
several mainly American com-panies decided to no longer watch
the endless discus-sions. With the end of the ISP project, they
began the definition of a new fieldbus optimized for the process
industry: the Foundation Fieldbus (FF). This work was done
outside the IEC committees within the ISA, and for some time, the
IEC work seemed to doze off. Following the failure to find an
acceptable draft for a universal fieldbus, the Europeans feared that it
might be impossible to get their national standards into an interna-
tional one. By that time, the standardization issue had ceased to
be a merely technical question. Fieldbus sys-tems had already made
their way into the market, much effort and enormous amounts of
money had been invest-ed in the development of protocols and
devices, and there were already many installations. Nobody could
afford to abandon a successful fieldbus, hence it was – from an
economical point of view – impossible to start from scratch and
create a unified but new standard which was incompatible to the
existing national ones. Within CENELEC, the national committees
found after lengthy discussions a remarkable and unprecedented
compro-mise: All national standards under consideration were
simply compiled “as is” to European standards [11]. Every part of
such a multi-part standard is a copy of the respective national
standard, which means that every part is a fully functioning system.
Although this approach is very pragmatic, it took a long time to
reach it, and the contents of the individual CENELEC standards
still reflect the strategic alliances that had to be formed by the national
committees to get “their” standard into the Eu-ropean one. To
make the CENELEC collection easier to handle, the various
fieldbus systems were bundled according to their primary
application areas. EN 50170 contains “General purpose field
communication systems”, EN 50254 “High efficiency
communication subsystems for small data packages”, and EN 50325
comprises different solution based on the CAN technology. In the
later phas-es of the European standardization process, the British
national committee played the part of an advocate of the American
companies and submitted also FF, DeviceNet, and ControlNet for
inclusion in the European standards. Table 2 shows a compilation
of all these standards, as well as their relation to the new IEC
standard. For the sake of completeness, it should be noted that a
compara-ble, though much less disputed standardization process
took place also for bus systems used in machine con-struction
(dealt with by ISO) as well as building automa-tion (in CEN and more
recently in ISO). While the Europeans were busy standardizing
their national fieldbus systems and sort of neglected what
happened in IEC, the Fieldbus Foundation prepared their own
specification. This definition was modeled after the bus access
scheme of FIP and the application layer pro-tocol of PROFIBUS-
FMS. The FF specification natural-ly influenced the work in the IEC
committee, and conse-quently the new draft evolved into a mixture
of FF and WorldFIP. When this draft was put to vote in 1996,
the actual fieldbus war started, and the casus belli was that
PROFIBUS was no longer represented in the draft. Giv-en the strict
European standardization rules where inter-national (i.e., IEC)
standards supersede opposing CENELEC standards, the PROFIBUS
proponents feared that FF might gain a competitive advantage and
“their” fieldbus might lose ground. Consequently, the countries
where PROFIBUS had a dominant position managed to organize
an obstructive minority that prohibited the adoption of the
standard by a narrow margin. The fact that the IEC voting rules
make is easier to cast positive votes (negative votes have to be
justified technically) was no hindrance, as there were still
inconsistencies and flaws in the draft that could serve as a fig-leaf.
However, the FF empire (as it was seen by the PROFIBUS sup-
porters) struck back with legal tricks to save the stand-ard. They
launched an appeal to cancel negative votes that had not
sufficient technical justification, which would have turned the
voting result upside down. They even proposed that the members
(i.e., the respective national mirror committees) should decide
about the (non-)acceptance of the incriminated votes – a procedure
which is not in conformance with the IEC rules and caused
substantial exasperation. In the course of subse-quent voting
processes, things grew worse: countries voting – both in favor and
against – that had never cast a vote before; votes not being counted
because they were received on a different than the designated fax at
the IEC and thus considered late; rumors about presidents of
national committees who high-handedly changed the conclusions
of the committee experts, and finally the substantial pressure
exerted by leading companies on the national committees. By and
large, the obstruction of the standard remained unchanged, and the
standardization process had degenerated to an economical and
political battle, which was apt to severely damage the reputation
of standardization as a whole.
4. The compromise
On the 15th of June 1999, the “Committee of Action” of the IEC
decided to go a completely new way to break the stalemate. One
month later, on the 16th of July, the representatives of the main
contenders in the debate (Fieldbus Foundation, Fisher Rosemount,
ControlNet International, Rockwell Automation, PROFIBUS user
organization, and Siemens) signed a “Memorandum of
Understanding”, which was intended to put an end to the fieldbus
war. The Solomonic resolution was to create a large and
comprehensive IEC 61158 standard accommo-dating all fieldbus
systems [12]. However, other than CENELEC, where complete
specifications had been copied into the standard, the IEC decided
to retain the original layer structure of the draft with physical,
data link, and application layer, each separated into a services and
protocols part (Table 3). The individual fieldbus system
specifications had to be adapted to so-called “types” to fit into this
modular structure. In a great effort and under substantial time
pressure the draft was com-piled, submitted for vote, and released
as a standard on December 31st, 2000. It was evident that the
collection of fieldbus specifica-tions in the IEC 61158 standard is
useless for any im-plementation. It needs a manual for the
practical use showing which parts can be compiled to a
functioning system and how this can be accomplished. This guide-
line was compiled later on as IEC 61784 as a definition of so-called
“profiles”. At the same time, the specifica-tions of IEC 61158
have been corrected and amended. The drafts of these documents
are currently under vote and can be expected to be put into
operation by the end of this year. These profiles show that the
international fieldbus today consists of seven different main
profiles that in turn can be subdivided (see Table 4). All im-
portant fieldbus systems from industrial and building automation
are listed here, and the world’s biggest au-tomation companies
are represented with their develop-ments. FF consists of three
profiles. The H1 bus is used in process automation, whereas HSE
is planned as an Ethernet backbone and for industrial automation.
The H2 is a remainder of the old draft. It allows for a migration of
the WorldFIP solution towards FF, but in the profile description it
is explicitly noted that there are no prod-ucts available. From the
PROFIBUS side, the two pro-files DP and PA are present, even the
new PROFInet has been included. Interestingly, the experts did it
not con-sider worthwhile to list the original version of
PROFIBUS, the FMS, which is a strong sign for the diminishing
importance, if not abandonment of this hard-to-engineer fieldbus
which is currently only contained in the EN 50170-2. The Danish
fieldbus P-Net was taken over like all definitions and variants of
WorldFIP and INTERBUS. In the latter case, also the extensions for
the tunneling of TCP/IP traffic have been foreseen in the
standard. A newcomer in the fieldbus arena is Swiftnet, which is
widely used in airplane construction (Boeing). The correct
designation of a IEC fieldbus profile is shown for the example
of PROFIBUS-DP: Compliance to IEC 61784 Ed.1:2002 CPF 3/1.
Table 5 shows some technical characteristics and the main fields of
applica-tion for the different systems. Low-level fieldbus sys-
tems for simple I/Os such as the ones based on CAN or the AS-
Interface are not part of IEC 61158, it is planned to combine them in
IEC 62026.

5. New challenges: Industrial Ethernet

In recent years, Ethernet has become increasingly popular in
automation. And like in the early days of fieldbus systems, this
boom is driven mainly by the in-dustry – on an academic level,
the use of Ethernet had been discussed decades ago. Hence the
initial situation is comparable to that 15 years ago, and there is
enough conflict potential in the various approaches to use Ether-net
in automation The future role of Ethernet in the automation area
is not clear. Initially, Ethernet was considered inappropri-ate
because of its lack of real-time capabilities. With the introduction of
switched Ethernet and certain modifica-tions of the protocol,
however, these problems have been alleviated. And even if there
are still doubts about the predictability of Ethernet [13], its the
penetration into the real-time domain will influence the use of
fieldbus-based devices and most likely restrict the future use of
fieldbus concepts. Today, Ethernet takes the place of mid-level
fieldbus systems, e.g., for the connection of PLCs. There exist first
applications in manufacturing and building automation where no
other fieldbuses than Ethernet are installed. To replace the
existing fieldbuses by Ethernet TCP/IP, these communication
protocols must also fit into one single ASIC. These requirements
of price and size is mandatory for simple devices connected to mod-
ern fieldbuses today. At the moment fieldbus connection circuits for
simple devices, often only one ASIC, are still cheaper than Ethernet
connections. Nevertheless, there exist different solutions to make
Ethernet and TCP/IP meet the (real-time) requirements of
industrial applica-tions [14]. The different approaches can be
classified in different groups (Figure 1):

5.1 Ethernet in IEC61158

Standardization has not intensively dealt with the question of
Industrial Ethernet yet. Still, in the wake of the fieldbus wars,
several solutions based on Ethernet and TCP/UDP/IP have made
their way into the IEC 61158 standard without much fighting (see
also Tab. 4): - High Speed Ethernet (HSE) of the Foundation
Fieldbus - Ethernet/IP of ControlNet and DeviceNet - PROFInet
defined by PROFIBUS International - TCP/IP over INTERBUS HSE
and Ethernet/IP (note that here IP intelligently stands for
“Industrial Protocol” to make confusion per-fect) are two
solutions with a fieldbus protocol being “tunnelled” over TCP/IP.
To be specific, it is no real tunnelling, where data packets of a
lower fieldbus OSI layer are wrapped in a higher layer protocol
of the transport medium. Instead, the same application layer
protocol which is already defined for the fieldbus is also used over
the TCP/IP or UDP/IP protocol stack. In the case of ControlNet
and DeviceNet, this is the Control and Information Protocol [15].
This solution allows the device manufacturers to base their
developments on existing and well-known protocols. The
implementation is without any risk and can be done fast. The idea
behind PROFInet is more in the direction of implementing a new
protocol. For the actual communi-cation, however, it was decided to
use the COM/DCOM mechanism known from the Windows world.
This solu-tion opens a wide possibility of interaction with the of-
fice IT software available on the market. The possibility to use
fieldbus devices like objects in office applications will increase the
vertical connectivity. On the other hand, this also includes the risk of
other applications overload-ing the network, which has to be
avoided. Basically, the COM/DCOM model defines an interface to
use modules as black boxes within other applications. PROFInet
of-fers a collection of automation objects with COM inter-faces
independent of the internal structure of the device. So the devices
can as well be virtual, and so-called proxy servers can represent the
interfaces of any underlying fieldbus. This encapsulation enables
the user to apply different implementations from different
vendors. The only thing the user has to know is the structure of
the interface. Provided the interfaces of two devices are equal, the
devices are at least theoretically interchangea-ble. Although this
proxy mechanism allows to connect Ethernet to all types of
fieldbus systems, it will not be a simple and real-time capable
solution. A second problem is that in order to achieve portability,
the COM/DCOM mechanism has to be reprogrammed for different
operat-ing systems. DCOM is tightly connected to the security
mechanisms of Windows NT, but there is also the possi-bility to use
WIN95/98 systems or – with restrictions – some UNIX systems.
To simplify this, the PROFInet runtime system includes the
COM/DCOM functionality, and the standard COM/DCOM functions
inside the oper-ating system have to be switched off if PROFInet
is used. The solution of tunnelling the TCP/IP protocol over a fieldbus
requires some minimum performance in terms of throughput from
the fieldbus to be acceptable. Nor-mally, throughput of acyclic
data (the transport mecha-nism preferably used in this case) is
not the strongest point of fieldbus systems. Nevertheless,
INTERBUS defines the tunnelling of TCP/IP over its acyclic
com-munication channel [16]. The benefit of this approach is the
parameterisation of devices connected to the fieldbus with standard
Internet services. However, this forces the manufacturer of the field
device to implement also the complete TCP/IP stack on the device
and the installation personnel to handle the configuration of the
IP address-ing parameters for the connected field devices

5.2. Alternative approaches for Industrial Ethernet

Outside the approaches that are already part of the IEC standard,
other solutions are proposed, which not yet entered the
standardization process. IDA (Interface for Distributed
Automation) is proposing a completely new protocol for real-time
communication over Ethernet and UDP/IP. It describes the model
elements and inter-faces in an automation architecture without
standardizing the engineering tools, device functions, or their
imple-mentation. Instead, it aims at supplying an object-oriented
infrastructure for modular, distributed, and reusable automation
solutions based on three main tech-nological pillars: an object-
oriented software model for mapping an interoperable engineering
and runtime archi-tecture, a seamless system-independent connection
level for all classes of communication, from I/O devices through
the control system to the management, the inte-gration of
channels for safety technology based on Ethernet TCP/IP, and
finally a standard browser-based Human Machine Interface for all
components of a heter-ogeneous automation solution through the
use of web technologies. The principle of tunneling is also used
for MODBUS/TCP [16] or BACNET. Like with CIP, the existing
fieldbus application layer is transported over the UDP/TCP/IP
protocol. The integrator of a multi-vendor installation uses Ethernet
TCP/IP as a common transport network, but he is still forced to
implement all the pro-posed application layers in his SCADA
(Supervisory Control And Data Acquisition) or controller system.
Unfortunately, there exists not just one single standard
Application Programming Interface (API). All the approaches to
use Ethernet and UDP/TCP/IP for industrial networking assume,
that Ethernet is low loaded or fast Ethernet switching technology
is used, in order to get a predictable performance. Switching tech-
nology does eliminate collisions, but delays inside the switches
and lost packages under heavy load conditions are unavoidable
also with switches. This gets worse if small switches are used in
a multi-level hierarchy, and results in jitter in cyclic
communication. As an alterna-tive, a consortium under the lead of
Bernecker & Rainer proposed an “Ehernet Powerline”. This
solution puts a master-slave communication protocol on top of
the standard Ethernet, which avoids all collisions. If used without
any switches, it gives fast cycle times (400 s) and very low
jitter. Ethernet can therefore be used for the synchronization in
motion control. For this solution, however, the free medium
access has to be modified. Additionally, the standard TCP/IP
protocol is only al-lowed in the time slice reserved by the master for
acyclic data transmission. In view of the different approaches, the
IAONA or-ganization has set to itself the goal to coordinate all these
activities and to end up with one Ethernet solution for the
automation world. At the moment, though, it is not visible how
this can be reached, as there are different major key player like
PROFIBUS International who do not participate in IAONA, while
others do just follow the debate without real participation. Inside
the IAONA organization the DEFIA working group
(Deterministic Ethernet for Industrial Automation) has created a
new proposal for a real-time protocol extension to Ethernet.
Finally, it appears that there are at least as many pro-posals for
industrial Ethernet as fieldbus standards exist already today.

6. Summary and outlook

In the past, we have seen more than ten years of fierce struggles to
get the current fieldbus standard. Now, after a short break, it seems
we are entering a new phase. The point of discussion is which
solution will be adopted for Industrial Ethernet, which is heavily
pushed by the in-dustry. But have the contenders learned their
lesson from the fieldbus wars? To date there are at least four different
solutions available in the international standards, and all major
manufacturers of automation devices have put in their solutions.
Most of the possible principles of com-bining fieldbus and
Ethernet are already included in the new standard IEC 61158.
Other innovative solutions are being proposed by dif-ferent
organizations. All of them have one major disad-vantage: They
create more degrees of freedom for the manufacturers and
implementers of automation devices to add more and proprietary
versions. The only proposi-tion which goes in the opposite way is
the initiative of the OPC Foundation: The development of OPC
DX offers for the first time the possibility of combining solutions
from different manufacturers and protocol families into one system.
This approach is, however, not capable of handling real-time traffic.
What will happen with the set of different approach-es? Like with
every industry-driven trend it is up to the market to decide which
technical solution will be adopt-ed best. As there are already some
solutions in the inter-national standard, we can anticipate that the
potential for conflicts is somewhat reduced. It is therefore
probable that the next battle will be only on the market and not
inside the standardization bodies, a situation we had in the
fieldbus area before the war about the international standards
began.