Proceedings 2003 IEEE International Symposium on
Computational Intelligence in Robotics and Automation
July 16-20,2003, Kobe, Japan
An Architecture for the Interconnecting Heterogeneous Fieldbuses
in Industrial Automation
R.T. Qu, Roland Lim
Singapore Institute of Manufacturing Technology,
71 Nanyang Drive, Singapore, 638075
Email: rtau@SMTech.a-star.edu.sg
Abstract
A wide variety of fieldbuses have been set up in the
industrial automation system in different time periods
under different environment. Therefore, during the
development of industrial automation systems and
control applications, the developer has to consider the
interconnection of heterogeneous fieldbuses. In the paper,
a Heterogeneous Fieldbuses Interconnection
Architecture (HFIA) is presented to interconnect
heterogeneous fieldbuses in wide area industrial
automation system. The HFIA provides an integrated
software hmework to interconnect heterogeneous
fieldbuses. With the help of the HFIA, it is easy and fast
to interconnect heterogeneous fieldbuses. At the same
time, the HFIA can be used for high-level industrial
applications to control, monitor and optimize the
operations of the fieldbuses systems. F’rofilbus, CANbus
and Ethemem are adopted as case studies for the HFIA
architecture.
1. Introduction
The research on fieldbus, at its beginning, focused on the
definition of the services and of new protocols to provide
the right quality of service for given kinds of application,
and for given distributions of control systems [l]. For
some years, the research has been oriented towards the
interoperability problems, the quality of service and
towards the design of system architectures [2].
A wide variety of fieldbuses are available in the market,
each one with its own special capabilities on the
different levels of ‘the hierarchical structure of industrial
automation [3]. Among the most famous fieldbuses are
Foundation Fieldbus, CAN, Profilbus, WorldFP and
LonWorks. In spite of the technological advances,
industrial automation lacks of the hymony that other
areas of industries have. The final effort for an
interoperable standard among the fieldbuses that was
carried on by the ISA’S SP50 standards committee
ended last year and resulted in an &standards standard
~41.
There are a lot of political disagreement and wrestling
for market share in fieldbus standards war. However, the
end users in the industrial automation business have a
clear need for interoperability and they want proven
solutions that can be deployed economically and
0-7S03-7866-0/03/$17.W 02003 lEEE
maintained well into the fnture. (Ideally these solutions
would also he buly interoperable -the point of having
any standard- but today’s reality dictates otherwise 151.
The concept behind fieldbus interconnection deals with
the convergence of heterogeneous fieldbus networks and
services, allowing interoperation and a uniform access to
users. This is an increasing demand fiom industrial
automation. Industrial automation is now facing the
challenge of interconnecting its resources to meet the
growing needs of the information society [6].
This paper describes some of our recent work in
developing the HFIA. The rest of this paper is structured
as follows. In Section 2, we introduce current status of
research in the interconnecting of heterogeneous
fieldhuses. Two strategies of interconnection are
discussed. Section 3 describes the HFIA used to
interconnect the fieldbuses. In section 4, we present the
detail design and implementation of the HFIA. In section
5, we give case studies based on Profilbus, CANbus and
Ethemem. Finally we give a conclusion.
2. Current status in the area of fieldbuses
interconnection research
The aim of distribution in industrial automation is to
increase modularity and flexibility, which is needed
while supplying highly customized products and systems
[7].Distributed industrial automation systems often use
fieldbus-based network solution. When the field devices
are interconnected with the same fieldbus, the design of
industrial automation application is an easy task. Data
and event interactions are mapped to the specific’s
fieldbus communication mechanisms. However, thiigs
are going to become more complicated, when the
application must be distributed among devices resided
on different fieldbuses. This is a common situation in the
industrial automation, where a lot of heterogeneous
fieldbuses have been installed in different time periods
under different situation [7]. The purpose of the
interconnection of heterogeneous fieldbuses is to
improve the interoperability in fieldbus level to solve the
problem.
What is meant by interoperability in the fieldbus level is
the ability of interconnecting independent fieldbus
segments, even from different vendors, in the ,
enterprise’s intranet backbone [SI. The solution is to use
396
Ius between each fieldbus and the enterprise i n m e t ,
leaving unchanged in this way the already defined
process of each bus, and transfemng only the necessary
data through the intranet. With the availability of cheap
memory and processing power, it is far more practical to
make a whole range of devices work with any bus
through an IU, without the need for converting the entire
product line to operate with an “alien” bus and all its
attendant hidden proprietary features. Ius will
theoretically appear to have intrinsic delays and
performance limitations -but practically, can be made to
operate with very little disadvantage. [3]
The Extended Fieldbus (EF) concept was first shown in
[9]. It enables several fieldbus segments to work
together by means of gateway nodes called IU through
network backbone [IO]. The functions performed by the
IU are basically: routing according to the address
scheme pertormed by the EF; encapsulation and de-
encapsulation of fieldbus messages; and service
scheduling for pending requests and responses [6]. The
IUS, or gateways, are interconnected through a common
network backbone. ATM as the network backbone was
proved to be a good solution for interconnecting
fieldbuses [ l l ] .
There are two strategies to interconnect fieldbus
segments via a network backbone in the EF architecture
[6]. The fust one is called Virtual Fieldbus (VF). The
second is called Independent Fieldbus (IF).
VF mainly focuses on the increase of the maximum
extension a fieldbus segment can reach. Two or more
segments of the fieldbus was organized as a virtual
fieldbus, that is mean there will be only one token for
token based fieldbus. The problem of the VF strategies is
it can only work for interconnecting of same kind of
fieldbus. Moreover, the evaluation results in [6] also
show IF has a better behavior over VF.
In the IF strategy, every fieldbus segments operate
independently. In case of token-based fieldbus, each
segment has its own token. In the IF h e w o r k , the Iu
can be treated as a normal fieldbus node in one fieldbus
segment. It should work as a master station in case of
master-slave structure. The UJ will also be a part of a
virtual IU network. A communication and messaging
protocol should be carefully designed for the
interworking unit network.
Although some kameworks for interconnecting were
proposed [6, 9, 121, their applications in industry are
very limited. There are four main problems of those
6ameworks. The first problem is those h e w o r k s
adopted ATM as network backbone to overcome the
real-time issue 19, 121. But ATM network is costly and
not broadly applied in industrial automation. In paper [6],
TCP/IP was used to interconnect the fieldbus segments.
However, capacity restrictions of TCPAP make it
impossible to meet the real-time requirements imposed
397
by industrial automation. The second problem is all
those frameworks only supported and investigated one
kind of fieldbus. It is more meaningful if two or more
kinds of heterogeneous fieldbus can be interconnected
together. The thud problem is the implementation of
tiameworks omitted the communication protocol
between interworking units, which is important to
improve the performance of the interconnection. The last
problem is those frameworks did not consider the issue
of interconnection of different kinds of fieldbus through
one IU. The industry is more interested in a cost-
effective, real-time and powerful solution for the
interconnection of heterogeneous fieldbus in real
industrial environment.
In this paper we present our architecture and
implementation for interconnecting heterogeneous
fieldbuses.
3. The Architecture of the Heterogeneous Fieldbuses
Interconnection
The first step to set up the HFIA is to choose a network
backbone. Although most researchers selected ATM as
backbone for heterogeneous fieldbus interconnection, we
still argue that Switched Fast-Ethernet should be another
good choice. There are compelling reasons to utilize the
Intemet Protocol (IP) for real-time systems. IP is quickly
becoming the lingua franca of the information age,
reaching into every area of modern life. Designs using IP
networking will be able to take advantage of this
connectivity, for instance by monitoring and debugging
systems remotely, collecting usage statistics, and even
notifying service personnel of impending failures 1131.
We chose Fast-Switched Ethernet as our backbone
network for HFIA due to its popularity, wide acceptance
and low cost. The network Architecture is shown in
Figure 1.
FIBMIUS A F3dbUIB
Figure 1. Network Architecture of HFIA
The next step is to select a strategy to interconnect the
fieldbus segments. The IF strategy was chosen that based
on the requirement to interconnect different kinds of
fieldbus, the ease of the IF strategy and performance
consideration.
The strict timing constraints imposed by the application
domain make the IU should operate as hard real-time. In
paper [SI,Function Block based mechanism was used to
implement the IU components. Thus, all data processing
is expected to recognize and to react to events. Although
this design methodology meets the IEC standard, the
heavy object model of FB makes it very difficult to meet
hard-real-time requirement. The key issue in the
implementation of the IU is how efficiently the IUScan
handle requests from remote and local fieldbuses.
Figure 2 shows our IU’s high-level software architecture
Y iesigned.
IU
Figure 2 Software Architecture of IU
It is composed of the following modules:
1. IU Execution Engine (IUEE)
2. Etbemet-based Real-time Message Bus (ERMB)
3. Universal Fieldbus Interface (UFI)
4. Application Interface (AI)
5 . Web based Human Machine Interface (HMI)
The IUEE is the brain of the IU. It controls the overall
execution of the IU.It is also responsible for generating,
coniigwing and recoofiguring the IU.When the IU starts
up, the WEE will read in the entire configuration file,
which is in XML format, to memory. The configuration
information is used for WEE to encapsulate and de-
encapsulate of fieldbus messages.
The UFI is defined to adopt the proprietiuy fieldbus.
The UFI is designed to translate the different commands
and data structures from different fieldbuses into the
commands and data structures that can be recognized by
the WEE. At the same time, if the IUEE needs to access
the fieldbuses, the UFI will translate the commands and
data structuresback to the formats that the fieldbuses can
accept.
In other frameworks, [9][12] real-time channel is
provided by ATM network with quality of Service (QoS)
naturally. Since Ethernet was selected for the backbone
of the HFIA, one of key issue of the decision is bow the
398
underline Ethemet can provide real-time communication.
Analysis results in [I31 show quite promising of using
UDPfIF’ to support real-time communication over
Ethemet. Therefore, to provide real-time communication
in Ethernet environmenf a real-time messaging protocol
must be designed and implemented.
The AI module will provide a unified interface for high-
level application to communication with the IU.
Basically, two type of AI are exposed. One OPC client
will talk to commercial OPC server to provide real-time
data. Another AI will provide connectivity to factory
database. All data that is available from local fieldbuses
and remote fieldbuses can be got from the two types of
AI. In paper [7],an OPC server module was designed for
the application interface. Again we drop this
methodology due to the efficiency consideration.
The Web based HMI enables the IU to be remotely
monitored and configured through Internet using web
browser. Thus user can access the IU from anywhere.
Based on Windows CE built-in web server, a web based
HMI was developed using ISAPI. This design is an
important step to make the IU to be deployed as an
embedded system without keyboard, mouse, monitor and
etc.
4. From Architecture to Implementation
4.1 Implementation of the IUEE
The WEE is actually a specified time-critical control
application. As the brain of IU, an efficient IUEE served
as the key issue of the success of the whole HFIA. It
reads and writes data frondto fieldbuses and ERMB. The
implement the IUEE will be very complex without the
support of engineering tools. Engineering tools to
support develop real-time control application in
Windows CE based embedded system is quite limited.
Luckily, we have such an efficient toolkit. The tool
oficial called SmartBox was jointly developed by Tata
Consultancy Services (TCS), Asia’s largest global
software solutions and consultancy services provider and
Singapore Institute of Manufacturing Technology [14].
The SmartBox Toolkit will be available for industrial
market in the coming April. An evaluation copy can be
got from TCS now. The detail of the SmartBox product
is available o n l i e through http://smartc.Simtecb.a-
star.edu.sg.
With the support of SmartBox, development of control
application in Embedded Windows CE is fast and easy
by using the Application Builder of the SmartBox. The
performance of the execution is also guaranteed by the
SmartBox platform. The detail of how to develop
control application using the Application Builder of
SmartBox is included in the manual of the SmartBox.
Only a few core module of the SmartBox is deployed
into the WEE based on its requirement.
4.2 Implement of the ERMB
As discussed in the previous section, an ERMB is
needed to enable real-time commyication over Ethemet.
An event-driven communication model was provided to
decouple interactions between different m E s . This
model is based on puhlisblsubscribe paradigm, and is
used to distribute data in the form of events. In
publisher/subscriber (producer-consumer) interactions
driven by events (usually the arrival or creation of data),
data producers are decoupled from data consumers---
they do not coordinate data &ansmission with each other,
except by using the same subject name. Producers
publish data to the network at large. Consumers place a
standing request for data by subscribing. Consumers can
listen for messages on any subject(,) on the network; a
subscription is an implicit request for messages.
Publishers anonymously broadcast messages onto the
network and subscribers anonymously receive messages
without having to request them. The detail of the
implement ofthe ERMB is documented in [15].
4.3 Universal Fieldbus Interface (UFO
Facing the problem of interconnecting different kinds of
fieldbus, the IU has to be able to provide a unified UFI
to the RTEE. A unified interface is developed for the
WEE to communicate with devices in order to execute
the request. The Figure 4 shows the architecture of the
UFI.
IUEE
Universal Fieldbus Interface
Figure 4 Architecture of the Universal Fieldbus
Interface
The UFI enables IUEEs to talk to the devices in different
communication protocols over different fieldbuses in
industry. The UFI includes a universal interface and a
communication proxy for different communication
protocols. The proxy talks to the MI provided by the
fieldbus card. We have already implemented three types
of protocols: EthemeUIP, CANBus and Profibus.
4.4AI and HMI
Two types of AI are implemented for the IU in the HFIA.
The two types of AI are implemented based on OPC and
Database technology respectively. Based on Windows
CE built-in web server, a web based HMI was also
developed using ISAPI.
399
5. CaseStudy
Two Profilbus segments, one CANbus segment and one
Ethemem are selected to do the case study for the
HFL4. Figure 5 presents the experimental network for
the HFIA.
ERMB
U1
1J"c IU2
E
Figure 5. Case Study Network Setup
Two embedded PC was selected to implement the IUS.
IU1 is linked to one Profilbus segment and one CANbus
segment. IU2 is linked to one Profilbus Segment and on
EthemeUIP segment. Here the Profilbus card and
CANbus card are from Applicom intemational.
The device connected to ProfilBusl is ABPLCS. It has a
total of 32 Digital Input and 32 Digital Output, 2
Analogue Inputs and 2 Analogue Outputs through four
AB's Digital VO modules 8-PT SIM A-B, and one AB's
Analogue VO Module 1771 NB4SC. The salve device
connected to Profilbus2 is OMRON PRTI-COM. It has
16 Digital Input and 16 Digital Output. Both Profilbus
run at a baud rate of 12 Mbits/sec. The CANBus devices
connected to CANBus are six PowerCube linear
modules. They are lid together to worked as a modular
Robot. The device connected through Ethemet is
EDAS1001. It has 32 configurable Digital VO. Some I10
in this device can also be configured to work as pulse
input or output.
Six types of interconnection activity are identified in the
system. They are:
1) ABPLCS to OMRON through Profilbus, W1,
ERMB, IU2 and Profilbus and vise versa.
2) ABPLC5 to PowerCube modules though
Profilbus, Tu1, CANbus and vise versa.
3) ABPLCS to EDAS though Profilbus, IU1,
ERMB, IU2 and Ethemet and vise versa.
4) PowerCube to EDASlOOlE through CANbus,
IU1, E M , IU2 and Ethemet and vise versa.
5 ) PowerCube to OMRON through CANbus, IUl,
ERMB, IU2 and h f i l b u s and vise versa.
6) OMRON to EDAS though Profilbus, IU2 and
Ethemet and vise versa.
The performance charactenstics of the six types of
interconnection activity are shown in Table 1. In the
table TI to T6 stand for the delay of the six types of
interconnection activity. Those results are mean values
obtained 6om the case study.
I T1 I 7.lmsec
4.5msec
39.5msec
28.4msec
6msec
I 28.lmsec I K.Thramboulidis, C.Tranoris, An Architecture for
Table 1. Performance characteristicsof
interconnection activities
The performance charactenstics of intemal module of
the HFlA are shown in Table2. In table2, TI” stands for
the delay of IU, TmB stands for the delay of ERMB;
Tppstands for the delay of the proxy of Profilbus; TPC
stands for the delay time of CANbus; Tw stand for the
delay of proxy of the Ethemet. Those results are mean
values obtained fiom the case study.
0.3msec
1.2msec
2.6msec
TPC 1Smsec
TPE 25msec
Table 2. Performance characteristics of intemal
modules
From the above two tables, we can see the real-time
performance is quite promising of most of the module.
The long time delay of the proxy of Ethernet is
investigated. The reason is due to the response time of
the EDAS device.
6. Conclusion
This paper bas presented our architecture for the
heterogeneous fieldbuses interconnection. The HFIA can
simplify the effort to interconnect heterogeneous
fieldbuses. The software framework for the IU was
implemented based on Windows CE real-time OS.
References
Decotignie J. D., Some future directions in fieldbus
research and development. In Fieldbus
Technology, Systems Integration;Networking and
Engineering, Proceedings of the fieldbus
Conference FeT’99, Springer, pp 308-3 12
Jean-Pierre Tbomesse, open issues in fieldbus
based systems, 15* Triennial World Congress,
Barcelona,Spain,2002
400
Jim Pinto, Fieldbus-Conflicting “Standards”
Emerge, but Interoperability is Still Elusive,
Design Engineering magazine, UK, Oct.99
Jim Pinto, The great Fieldbus debate is Over!,
proceedings of Industrial Control Intelligence, Nov.
1999
David March, Surviving the fieldbus wars, EDN
magazine, April, 1999
Victor M.Sempere, Jorge Mataix Oltra, Estanislao
Utrilla Gines, Modelling of Systems for the
InterConnection of Industrial Communication
Netwoks Through Intemet, EUNICE’99
the development of Function Block Orient
Engineering Support Systems, IEEE International
Symposium on Computational Intelligence in
Robotics and Automation, August ,Canada 200 1.
C.Tranoris, S . aslanis, K.Thramboulidis, Using
RT-Lmux for The Interconnection of Industrial
Fieldbuses, proceedings of Fist National
Conference on Recent Advances in Mechanical
Engineering, AMSE Intemational-Greek Section,
Patras, Greece, Sep. 2001.
Kunert (o.), Interworking field buses through
ATM: Proceedings of 2nd IEEE Workshop on
Factory Communication Systems 1997, Barcelona,
Spain, 1-3 Oct. 1997
Victor M.Sempere, Jorge Mataix Oltra, Estanislao
Utrilla Gines, “Simulating a Wide Fieldbus
Interconnected through ATM for its Real-time
Performance Evaluation”, European Conference on
Networks & Optical Communication. ISBN-90-
51994001(IOS Press) June 23-25, 1998,
Manchester (UK).
Cseb, C. et al., “ATM network for factoxy
communication”, proceedings ETFA’99
C.Tranoris, K.Thramboulidis, Interconnecting
Heterogeneous Fieldbuses in Wide Area Industxial
Environments, WSCEAS, Multiconference, Greece,
July, 2001
G. Pardo-Castellote, and A.S. Schneider The
Network Data Delivery Service: Real-Time
Connectivity for Distributed Control
Applications,” IEEE lntemational Conference on
Robotics and Automation, San Diego, CA, 1994
Z.Q. Ding, A. Aendenroomer and H.He,
Development of a federated embedded controller,
technique report of Singapore Institute of
Manufacturing Technolo&, wwwS1MTech.a-
~
star.edu.sp 2002
R.T. Qu, A. Aendenroomer, Distributed Multi-
Level Real-Time Message Bus lnh.struchue Over
Etbemet, technique report of Singapore Institute of
Manufacturing Technology, www.SIMTecb.a-
star.edu.sq, 2002