ISA Transactions 48 (2009) 132141

Contents lists available at ScienceDirect

ISA Transactions
journal homepage: www.elsevier.com/locate/isatrans

A fieldbus simulator for training purposes

Eduardo Andr Mossin, Rodrigo Palucci Pantoni , Dennis Brando
School Engineer of So Carlos - University of So Paulo, Brazil

article

info

Article history:
Received 14 May 2008
Received in revised form
25 July 2008
Accepted 29 July 2008
Available online 30 August 2008
Keywords:
Fieldbus automation systems
Simulator
LabView

a b s t r a c t
This article presents a fieldbus simulation platform and its remote access interface that enables a
wide range of experiments, where users can configure operation sequences and procedures typical of
Foundation Fieldbus systems. The simulation system was developed using LabVIEW, with requisites of
deterministic execution, and a course management work frame web server called Moodle. The results
were obtained through three different evaluations: schedule table execution, simulator functionality
and finally, simulator productivity and achievement. The evaluation attests that this new tool is feasible,
and can be applied for fieldbus automation systems training purposes, considering the robustness and
stability in tests and the positive feedback from users.
2008 ISA. Published by Elsevier Ltd. All rights reserved.

1. Introduction
The use of automatic electronic devices in the process control
industry is nothing new. Since 1970, these devices have been
used first in direct digital control (DDC), and then in distributed
control system (DCS) or programmable logic controllers (PLC).
The spread of microcontrollers technology in the 90s enabled
the development of smart field devices, the main characteristic of
which is having their own intelligence and function [1].
Considering that the intelligence of a control system is
distributed over each smart device on the shop floor or on
the plant, the next step is interconnecting all devices, and
creating an instrument network [2], nowadays called fieldbus, with
requisites of real time systems. Fig. 1 shows the basic architecture
of a fieldbus network, composed of field devices, the fieldbus
communication channel, the controller unit(s) and specialized
engineering host stations.
The great interest in this network model led several manufactures to implement their own communication protocols, to enable communication among their devices, and during the last two
decades, some criteria were defined in order to standardize the
communication model, and enable communication among different models of devices, developed by different manufacturers.
There are several standard and widespread fieldbus protocols
available in the market, such as CAN (Control Area Network),
Interbus, DeviceNet, Hart, Modbus, AS-I (AS-Interface), Profibus
and FOUNDATION Fieldbus. This article refers to the FOUNDATION

Corresponding author. Tel.: +55 16 33739357; fax: +55 16 33739372.

E-mail address: rodrigoppantoni@yahoo.com.br (R.P. Pantoni).

Fieldbus (FF) protocol, one of the fieldbuses designed for typical

industrial process control applications.
The combination of two or more protocols on integrated
hybrid systems, as well as the use of such systems on process or
equipment with fast dynamic responses, motivates the scientific
community to evaluate the performance of networked control
systems (NCS). Such studies result in advances and optimization of
transmission media technologies, communication methods, new
smart transmitters capabilities (sensors, controllers and actuators),
as well as advanced industrial control strategies.
Although being standardized, there are complex concepts
and architectures behind these systems and, therefore, the
learning curve for this technology is slow, considering the large
amount of required professional background on the areas of
instrumentation, software engineering and digital communication.
An important aspect when considering the learning process of the
fieldbus technology is practical experience. There are considerable
safety and economical restrictions on the access of students,
researchers and plant operators on training processes, to a real
operating industrial plant. Even bypassing the need for real plant,
projecting and assembling a small plant destined only for training
purposes would certainly be considered an interesting option. This
alternative leads as well to certain restrictions, such as engineering
costs, capital expenses and the low flexibility for executing a
broad range of experiments and situations during the training or
a particular study.
In this context, the use of training simulation tools should
be also considered. By using this class of tools, researchers,
professionals and students can simulate the dynamics and the
communication of complete fieldbus networks, in order to
understand, evaluate and practice its operation on network
configuration, device commissioning, plant start up, and system
operation in automatic or manual modes.

0019-0578/$ see front matter 2008 ISA. Published by Elsevier Ltd. All rights reserved.
doi:10.1016/j.isatra.2008.07.005

E.A. Mossin et al. / ISA Transactions 48 (2009) 132141

133

Fig. 1. Basic fieldbus network architecture.

Typically, simulation tools force the students, professionals

or researchers to go to a laboratory to execute their tests and
chores. Due to the increasing availability of the Internet on
academic and industrial facilities, remote access through the
Internet to simulators and plants shall be considered, because of
the possibility to separate these resources from users.
In fact, the use of simulations can be complementary to
traditional training methods and facilities, or in a second approach,
it can be considered and projected as flexible and realistic enough
to be used as a main training tool.
This paper presents a web enabled simulation tool for networked control systems, designed according to the FF specification
and aimed to be applied in industrial training programs and in academic disciplines. The proposed simulation tool is named FBSIMU,
and is focused on the user application layer, attending to requisites of realistic operation procedures and interfaces, and of real
time simulation dynamics. Its range of experience goes from fieldbus system configuration and commission, to handling events and
alarm conditions.
This paper is organized in eight sections, including this
introduction. The next section introduces some characteristics of
the FOUNDATION Fieldbus protocol and application process, used
as a model to design the FBSIMU architecture. This architecture
and the resulting simulation platform are explained later on the
section FBSIMU Architecture. The description of a typical training
application of the FBSIMU closes section three.
Section 4 is comprised of a brief state-of-the-art and examples
of remote laboratories focused on e-learning of industrial automation in a broader sense, and control systems disciplines.
The Internet access mechanism and the clientserver model
of cooperation proposed for the remote use of the FBSIMU are
presented in Section 5.
In Section 6, the practical tests and results obtained by the use
of the FBSIMU online version are presented. The analyses of the
results are discussed in the Section 7.
Finally, the authors discuss new perspectives for development
and application of the FBSIMU tool, and the identification of trends
on distance training models, dedicated to industrial automation
and distributed control systems.
2. The Foundation Fieldbus protocol
The term FOUNDATION Fieldbus indicates the protocol specified by the Fieldbus Foundation. It is a digital, serial, bidirectional,
and distributed protocol, which interconnects field devices such as
sensors, actuators and controllers. Basically, this protocol can be

classified as a LAN (Local Area Network) for instruments used in

process and industrial automation, with the ability to distribute the
control application through a network.
This protocol is based on the ISO/OSI (International Organization for Standardization/Open System Interconnection) sevenlayer reference model [3]. Although being based on the ISO/OSI
model, the FF does not use the network layer, the transport layer,
the section layer, nor the presentation layer, because it is restricted
to local applications. The entire network structure of the FF concentrates on the physical layer, the data link layer (DLL) and the application layer. Besides these three implemented layers, the protocol
defines an additional layer called User Application Layer.
The FF Physical Layer, named H1, uses a shielded twisted pair
cable as a communication medium. The H1 specifies a 31.25 kBit/s
baud rate with Manchester bit codification over a bus powered
channel. The network topology configuration is flexible: it is
typically configured with a trunk and several spurs, attending
certain physical and electrical limitations regarding maximum
length and number of transmitters.
The DLL carries the transmission control of all messages on
the fieldbus and its protocol grants to the FF network temporal
determinism. The communication is based on a masterslave
model with a central communication scheduler (master), named
Link Active Scheduler or LAS. This node performs the medium
access control (MAC).
Two types of DLL layer are standardized: Basic and Link Master.
A Basic DLL transmitter does not have LAS capabilities, it operates
passively as a communication slave. A Link Master DLL transmitter,
on the other hand, can execute LAS functions and thus, if the active
LAS node fails, become the LAS node.
The FF Data Link Layer supports two transmission policies: one
addressed to scheduled cyclic data, and another to sporadic (unscheduled) background data. These two communication policies
share the physical bus, but they are respectively segmented in
cyclic time slots or periods. In the scheduled communication period, most process variables generated by periodic processes are
transmitted cyclically according to a static global schedule table
loaded on the LAS node. This cyclic transmission mode has higher
priority over acyclic transmission modes.
A periodic process can be defined as a process initiated at
predetermined points in time, also called a time-triggered process.
The period for this class of process is typically some milliseconds,
and it is mandatory to consider that the generated data must be
delivered before the next data is available. This type of periodic
data is usually related to measurement and control variables [4].
Sporadic or unscheduled communication is used to transmit
non periodic, or aperiodic, data generated by sporadic processes

134

E.A. Mossin et al. / ISA Transactions 48 (2009) 132141

not directly related to the control loop cycles, but to configuration actions and data supervision efforts. The unscheduled transmissions are dispatched under a token pass scheme. A token that
circulates among all active nodes on the bus is used in FF protocol.
Once a transmitter receives the token, it is granted the right to send
pending aperiodic messages with a minimum priority for a specific
time period.
Non periodic (or event-triggered) processes are initiated as
soon as specific events are noted [5]. The event-triggered processes
are unpredictable and usually related to alarm notifications,
configuration data and user commands as cited before. Although
acyclic traffic is less frequent than the cyclic one, the acyclic data
should also be delivered prior to a certain time deadline, according
to the system requirements.
For a description of the MAC operation on both cyclic and acyclic
phases, refer to [68].
The FF User Layer is directly related to the process automation
tasks themselves, and it is based on distributed control or
monitoring strategies of Function Blocks. Function Blocks (FBs)
are User Layer elements that encapsulate basic automation
functions and consequently make the configuration of a distributed
industrial application modular and simplified [9]. Distributed
among the transmitters, the FBs have their inputs and outputs
linked to other blocks in order to perform distributed closed
control loop schemes. When blocks from different transmitters are
linked together, a remote link is configured and mapped to a cyclic
message. Considering that all cyclic messages should be released
in a predetermined instant defined on a schedule table, and that
they carry data generated by the FBs, it is adequate to synchronize
the execution of the FB set on the system with the referred cyclic
transmissions schedule table. This solution leads to the concept of
joint scheduling [10].
The Foundation Fieldbus standardized a set of ten basic
function blocks [11], a complementary set of eleven advanced
control blocks [12], and a special flexible function block intended
to be fully configurable, i.e., internal logic and parameter, by
the user [13]. The standard and advanced block sets provide
mathematical and engineering calculations necessary to configure
typical industrial control loop strategies, while the flexible
function block can be applied to custom or advanced controls or to
complex interlocking logics based on ladder nets. It is important to
state, however, that the standard is open at this point, permitting
the integration of user-defined custom function blocks in order
to enhance the capabilities of FF control system, and make the
integration of novel control techniques possible.

3.1. Function Block simulation

The Function Block modules are programmed into the FBSIMU
according to the FF specifications directions and, consequently, the
usage and configuration of a simulated control loop on the FBSIMU
environment is identical to a real FF system.
A VI library has been developed [15] to provide a range of
typical Foundation Fieldbus control and acquisition functions,
according to the standards. Another VI functionality facilitates
the development and integration of standard and custom FBs to
the system. These functions encapsulate different FF calculations
and data type manipulations necessary to build Function Blocks,
configuring a LabVIEW Foundation Fieldbus Tool Kit. A Function
Block seed module is also used to facilitate the process of
developing and integrating new projects. The seed has the whole
FB module structure (an empty structure) and directions to
proceed with a FB project from the design to the final test
procedures.
Each FB module is built as two different versions that share the
same FB core: stand-alone and process. The stand-alone FBs are
executed by user commands and controlled by its front panel. Its
execution can be performed independently of any other module,
so the user is able to test the FB and simulate its operation
under a controlled condition of inputs and outputs. The graphical
user interface is intuitive and enables the user to execute the FB
continually or in a step-by-step mode.
The process version of a FB, on the other hand, is controlled
remotely likewise real FBs. Each process FB has a unique
identification and its operation is controlled by the user through
the following commands:
- FB_Read: this service allows the value associated with a block
parameter to be read.
- FB_Write: this confirmed service allows the value associated
with a block parameter to be written.
- FB_Exec: this service triggers the block algorithm to be
executed.
- FB_Reset: this service allows default values associated with all
block parameters to be written.
Process FBs do not have front panels; they are instantiated by
the FBSIMU.CONF in each simulation process. The communications
between process FBs and the FBSIMU.CONF are performed
programmatically and dynamically by the LabVIEW function Call
by Reference Node. It is important to note that the industrial
transmitters are not considered in the FBSIMU architecture,
i.e., function blocks are instantiated on the simulation without
being allocated in specific virtual transmitters. The FBSIMU.CONF
module front panel for fieldbus configuration is shown in Fig. 2.

3. FBSIMU architecture
3.2. Physical plant simulations
The basic concept of the FBSIMU architecture is to map each
Function Block, as well as the plant, in an independent LabVIEW
application, also named Virtual Instrument (VI). The configuration
of the whole system is centralized in the FBSIMU.CONF module.
This modules front panel (GUI) is inspired by commercial fieldbus
configuration tools.
As mentioned before, the FBSIMU is focused on the function
block application layer and it is composed exclusively of software
according to a modular and extensible architecture. The simulator
was developed in LabVIEW using the G graphical programming
language, native language in this environment. Each FBSIMU
module or software unit simulates an element or a structure of a
real FOUNDATION Fieldbus system [14].

The plant module cyclically executes a discrete single variable

(SISO) linear ARX (Auto-Regressive with Exogenous Inputs)
mathematical structure [16]. This module is configured by the
FBSIMU.CONF and simulates the controlled plant. The adopted ARX
structure is represented by Eq. (1), where k is the discrete time
instant, Y is the output vector, U is the input vector, i is the number
of MIMO plant inputs and outputs, na is the number of output
regressors, and nb is the number of input regressors. In the current
version, i is set to 1 (one) to reflect a SISO model.
Yi1 (k) =

na
X
s=1

Asii Yi1 (k s) +

nb
X
s =1

Bsii Ui1 (k s) . (1)

E.A. Mossin et al. / ISA Transactions 48 (2009) 132141

135

Fig. 2. FBSIMU.CONF module front panel for fieldbus configuration.

Fig. 3. FBSIMU.CONF module front panel for plant configuration.

The simulated plant dynamic behavior is modeled on the dynamic

matrixes A and B. It must be observed that the number of regressors
limits the model dynamic order in the actual version it is limited
to third order systems and that all regressors must be initialized
prior to starting the simulation. A white noise generator function
adds a simulated acquisition noise to each plant output bounded
by user configurable amplitude.
As the user chooses the plant order (1st, 2nd or 3rd) and
dynamics (gain for 1st and 2nd order systems, damping ratio,
natural frequency and time constant), the selected plants Bode
Magnitude Chart, Pole-Zero Map, Root Locus Graph and the Step
Response are instantly presented on the front panel. The third
order system is composed of a first order system in series with a
second order one, both adjustable by the user, as stated.
A white noise signal can be also introduced with configurable
absolute amplitude over the plant output. Fig. 3 shows the
FBSIMU.CONF module front panel for plant configuration.

3.3. Simulation architecture

The proposed execution model for the fieldbus simulation on
FBSIMU can be considered hybrid, because some tasks are eventdriven, while other tasks are time-triggered. All tasks related to
the user interface are event-driven, they are executed after a user
action, such as selecting a new block, configuring schedule table,
saving a configuration or starting the execution.
On the other hand, the tasks related to executing FBs according
to a schedule table, plant simulation, and online monitoring of FBs
are time-triggered.
Due to the fact that all tasks are performed on a single
microprocessor, they are, naturally, concurrent. The proposed
solution for preventing unexpected delays of time-triggered
tasks (considered critical) due to executing event-driven tasks
(considered non-critical) is adopting priority levels for each task
and preemptive execution mode.

136

E.A. Mossin et al. / ISA Transactions 48 (2009) 132141

Table 1
FBSIMU task set
Module

Priority

Execution

Timeout

Determinism

GUI & User commands

FB schedule
Plant execution
Online FB parameters monitoring

Lowlow
Highhigh
High
Low

Event driven
Time triggered according to the schedule table
Periodic with configurable period
Periodic with period = 500 ms

1s
No
No
No

No
Yes
Yes
Yes

Fig. 4. FBSIMU block list.

Fig. 5. FBSIMU schedule table.

In the preemptive execution mode, a higher priority task that is

ready to execute preempts all lower priority tasks, which are also
ready to execute or actually during execution.
Table 1 summarizes the FBSIMU task set and its timing and
execution characteristics.
3.4. A typical simulation experiment
The intrinsic flexibility of simulation tools opens a wide range
of FBSIMU experiments, where users can exploit the effect of
important communication parameters and configurations found in
industrial FF systems. Practical experiments consist of comparing
given simulated fieldbus system performances over different
operation conditions. The results can be analyzed via log files or
graphically on charts.
For typical simulation training, the FB control strategy should
be defined. Then, the period of the macrocycle must be set
in milliseconds, and all the release times (in milliseconds) of
each FB execution and FB link must be defined regarding the
macrocycle start instant. Figs. 4 and 5 present an example of these
configurations on the FBSIMU.
The configuration parameters from all FBs on the schedule table
must be set in a parameter table, as shown in Fig. 6, to support
the proposed strategy (for example, Block Mode, Scaling, Gains),
exactly likewise a real block strategy configuration.
The last step is to link the input and output parameters from the
AI and AO blocks to the plant simulation module, as represented in
Fig. 7.
The connection between an Analog Output block (AO) and
the plant input (manipulated variable MV) and the connection
between the plant output (primary value PV) and the Analog
Input block (AI) are configured by the user for close loop
experiments. Alternatively, the user may connect only the plant PV

to the AI block for an open loop simulation, or manually load the

plant PV with a given numeric value.
Finally, the user downloads the configuration to each FB, and
starts executing the schedule. During the execution, it is possible
to monitor the parameter table with online parameter values and
register the parameters on text files for further analysis.
With the FBSIMU architecture, the FF operation scenarios
can be configurable and different sequences of practice training
can be defined to embrace fundamental concepts of fieldbus
control systems, as well as practical situations of alarms or
events handling. This characteristic is considered important
by the authors, because most of the traditional pilot plants
equipped with fieldbus instrumentation offer just one or a few
scenarios, whereas a full sequence of practice experiments should
be based on it. Thus, the use of a simulated fieldbus system
enables a flexible evaluation of the contribution and effect of the
communication protocol on the overall system dynamics, which
is an impossible goal considering that, in pilot plants equipped
with real instrumentation, most communication configurations
are fixed and, in most cases, inaccessible to end-users.
4. On-line laboratories in automation and industrial control
area
It is possible to identify three distinct approaches in the
literature associated with distance learning methodologies, used
in the Automation and Industrial Control area.
The first one is based on remote access to laboratories
with real instruments. The second one is the remote access to
dynamic simulators for control loops and, eventually, for industrial
instruments. The third approach, currently in disuse, is based on
on-line tutorials, where users have some information about a
subject but do not have interactive methods of learning. A simple
activity, showed in [17], can be performed through a tutorial where
a user copies commands from a web page and pastes them in
MATLAB. After executing the application, the analysis of the results
is guided by explanations contained in the on-line tutorial.
A simple comparison can be made by focusing the first two
approaches. First, it can be concluded that the advantage of the
simulation method is that it allows the user to conduct any
type of experiment without security restrictions or concerns. A
disadvantage of simulation systems is that it does not provide a
more realistic experience with industrial equipment to the users.
Considering these tools, Section 4.1 shows some examples
of laboratories with remote access to real control systems and
Section 4.2 shows examples of remote access to simulations. Then,
Section 4.3 shows the examples of remote laboratories which
provide access to pilot plants using fieldbus protocols.
4.1. Remote access to real instruments
An example of this approach is described in [18]. It is composed
of an environment for distance operation of a real testing plant
through the Internet. The plant, an inverted pendulum, is located
near the server machine. The system was developed with the
purpose of not showing the physical plant characteristics to the
user, and therefore, the system can be easily adapted to other
plants located in this laboratory. An important characteristic of this

E.A. Mossin et al. / ISA Transactions 48 (2009) 132141

137

Fig. 6. FB parameter table.

Fig. 7. Plant simulation module.

work is that professors can add different experiments by simply

editing the configuration file.
Also exemplifying didactic experiences through remote access
to real plants, a system that allows the users to access instruments
through the web is described in [19]. In this system, instructors
can configure equipments even during a class. The system
architecture is composed of a server machine connected to
different instruments (sensors, actuators, motors, power supplies),
and equipment control is performed by a LabVIEW application.
With remote access through the web, the instructor connects to
the LabVIEW to modify different instruments parameters, thus
having the ability to take different directions in his/her classes. In
this system, the user has limited access to some parameters due to
security reasons.
In [20], the remote access to a laboratory with four types of
control loops (manual and PID control, space state algorithms and
fuzzy logic) was implemented. Also, in this laboratory, it is possible
to remotely access a platform where researchers execute tests on
control algorithms. The system supplies images and sounds from
the laboratory through a camera built in a mobile platform. The
plant used in the experiment consists of coupled tanks.
4.2. Remote access to simulation tools
Experiments that involve tutorial sections, theoretical exercises
and experiments in simulated plants have been explored through
a system based on a MATLAB/Simulink plug-in for remote access,
Maple and Java applet [17]. The disadvantage of this system is that,
although the system is accessed remotely, the client machine must
have the MATLAB software installed locally.
Another example is a tool that simulates a Digital Signal
Processing (DSP) laboratory [21]. The laboratory has five exercises
which cover Z-Transform theory, Frequency Response, Fourier
transform and other control topics. The tool provides web pages

that describe the proposed exercises and support programs in Java,

allowing users to develop their own system simulations.
Focusing on the teaching of theoretical bases of control systems,
a tool that covers several techniques for control systems analysis
under the classic and modern theories was created [22]. The tool
supports models represented in both state space and transfer
functions notations. The user, using a web browser, can choose the
project and analysis methods of a controller, specify the type of
control system and configure its parameters. Data is sent to a server
for numerical computation and results are sent back to the client.
On-line experiments that allow comparing the performance of
different controllers, such as PD and PID, in situations of set point
changes and disturbance, are also explored [23]. The author affirms
that simulations are excellent for theory assimilation, but they
cannot substitute a real experiment in the laboratory.
4.3. Distance learning of Fieldbus protocols
Beyond control theory, some cases of distance learning explore
the teaching of fieldbus protocols. An example of a virtual
laboratory focusing on the CAN protocol (Controller Area Network)
can be cited [24]. This laboratory, called Virtual Automation Lab, is
an interactive tool for distance learning of CAN protocol operation.
The tool can be used in two ways: first, as a real laboratory
connected to the Internet using a remote interface, where the
user operates a real device and observes characteristics of fieldbus
networks, such as communication delays, fails, etc; and second,
through simulations that allow users to get used to this type of
fieldbus system before handling real instruments. The experiment
uses a PC, one web cam, some intelligent transmitters operating
with CANopen protocol and a CAN interface board. The stages of the
course cover motivation, group objectives, educational objectives,
general vision and exercises. To complete an exercise, the devices
must be available for use (only one user can access the devices per
time) and some security restrictions must be considered.

138

E.A. Mossin et al. / ISA Transactions 48 (2009) 132141

Fig. 8. FBSIMU On-line architecture.

Using another fieldbus protocol, an experimental practice

with remote access to a pilot plant explores the basics of the
FOUNDATION Fieldbus protocol [25]. This remote access allows
the user to execute experiments and supervise a pilot plant.
This system is also used as a platform for industrial automation
research. The adopted pilot plant consists of three coupled tanks,
flow pumps and five control valves used to manipulate the
outflows of liquids in the system. It is possible to configure several
control strategies using the tank level variables, outflows and
temperatures. The system architecture follows the clientserver
model. The client is an applet that communicates with the
web server using sockets. The SCADA software is installed on
the server with an OPC interface, which receives information
from the fieldbus network. The SCADA software creates a web
page with all the necessary process data and makes them
available to the remote user. The system has also a web cam
for visual tracking of the plant dynamics. As auxiliary functions
to the training procedures, the system contains user access
control, a sub-system for scheduling experiments, a method for
monitoring the duration of practical sections and a configuration
area in which users can set some parameters from the control
system. Since the system is composed of a real pilot plant,
experiments cannot be executed by more than one user at the same
time.
5. Online FBSIMU
Aiming to provide the flexibility for users access to fieldbus
learning systems and to follow the distance learning tendency, an
online version of the FBSIMU platform is described in this section.
The online version of the simulator is based on the clientserver
model. The server executes several instances of the FBSIMU and the
clients are the users computers.
On the proposed model, two additional functions were added to
the local scheme simulation, described on the previous sections, in
order to coordinate the remote transactions. The main additional
function is related to user access control. The other functionality
is an online questionnaire that registers information related to the
users learning process for future efficiency analysis of the remote
model.

5.1. Server side

The FBSIMU server is composed of two web servers. The first
server is responsible for user access control, forums, links, and
the questionnaire. This server was developed through a Course
Management System (CMS), a configurable framework, whose goal
is to organize and speed up the creation, management, distribution
and publication of information in remote courses context. The CMS
offers features that allow the web master to execute the whole
content management process from web browsers, in a remote way.
Moreover, the CMS offers a framework with some features already
implemented, such as access permission to the system.
There are different types of CMS available in the market and
most of them are open source projects. The CMS Moodle [26] was
used in the on-line FBSIMU implementation.
Moodle is an open-source software licensed under GNU GPL
(General Public License), maintained and revised by a community
of users and developers. The software is developed with the PHP
script language; it stores data in a MySQL database and uses Apache
as its web server.
The second web server deals with remote access to the FBSIMU
environment itself. This access is performed through a native web
server embedded in the LabVIEW. It is activated by the FBSIMU
modules, i.e., the FBSIMU VIs (Virtual Instruments).
Through this web server, a user can access the VI, using a web
browser. For the web browser to access the VI, it is necessary to
install the LabView Runtime Engine in the client machine. This
software can be downloaded from the National Instruments Home
Page or the LAI Home Page (http://lai.sel.eesc.usp.br/moodle/).
Considering that LabVIEW and Moodle work with different web
servers (Moodle uses Apache while LabVIEW uses its own web
server), this section describes the integration of both servers.
The integration is achieved with a database, where user access
information for each FBSIMU instance is stored and read by both
Moodle and LabVIEW. Fig. 8 shows the basic architecture for this
system.
Following this architecture, steps i, ii and iii illustrate the
communication flow between the client workstation and the
server:
(i) Moodle validates the user who tries to log in the system. At
this moment, the user may or may not have permission to
access the FBSIMU.

E.A. Mossin et al. / ISA Transactions 48 (2009) 132141

(ii) User with permission accesses the FBSIMU link. At this

moment, the system executes a PHP code that controls which
users are operating the system. This information is stored in
the database. After executing the validation, another PHP code
generates a HTML file that will be used on the access of the
FBSIMU instance. Generated such archive, the access address
is returned transparently to the client workstation.
(iii) This address is a response to a PHP call, and when this value
is received by the client workstation, a new Web navigator
window will open, pointing to this address. Then, the accessed
HTML will link the client workstation to the FBSIMU instance.

Table 2
Schedule table configuration
Task

Release time (ms)

AI
PID
AO
AI.OUT PID.IN
PID.OUT AO.CAS_IN
PID.BKCAL_OUT AO.BKCAL_IN
Macrocycle period

0
300
600
100
400
700
1000

Table 3
Experimental timing measurements

5.2. Client side

On the client side, the first web page shows a brief description
of the experiment and the link for the user log-in page. This web
page is provided by the Moodle module through the Apache web
server.
After the user logs on the system, he/she can access the FBSIMU
tool. Access will be provided by the LabVIEW embedded web
server.
Besides the FBSIMU access, the system proposes a questionnaire, which registers information related to the users learning
process for a future efficiency analysis of the educational model,
as cited before.
6. Results
The results were obtained through three different evaluations:
schedule table execution (Section 6.1), FBSIMU functionality
(Section 6.2) and productivity and achievement (Section 3).
The schedule table execution test and the FBSIMU functionality
functional test were performed in order to verify the timing
precision, robustness and stability of the FBSIMU running over the
Internet.
On the schedule table execution test, a static schedule table was
configured and, based on this table, the test was executed under
four simulation operational conditions in order to verify the timing
precision of the schedule table dispatch mechanism, the most time
critical process in the simulator.
On the FBSIMU functionality test, the robustness and the
stability of the FBSIMU online version were tested, when accessed
by a group of five concomitant users. This group of students
executed a test routine where all system features were evaluated.
The use of the distance education methodology is sufficiently
spread out, and its effectiveness has been already proven [27].
In order to evaluate the users productivity and their achievement on the learning process with the use of the FBSIMU on
a remote scheme, a class of 25 undergraduate industrial automation students executed a regular FBSIMU experiment and
answered a questionnaire. Another questionnaire was used to
evaluate the instructors impression about the tool (productivity and achievement test). These questionnaires are published at the Industrial Automation Laboratorys Moodle website
(http://lai.sel.eesc.usp.br/moodle/) with access constraints.
6.1. Schedule table execution evaluation
These tests were performed with five students from the
Industrial Automation Laboratory.
For this test, a PID Control strategy composed of three Function
Blocks (AI-PID-AO) was configured, and a schedule table was
proposed for its execution. The schedule table and the macrocycle
period configuration are presented in Table 2.
The LabVIEW system clock value was registered at the release
instant of each task at the scheduling table. The macrocycle period

139

Average period
Standard deviation
Max. value
Min. value
Number of samples

Cond. 1

Cond. 2

Cond. 3

Cond. 4

999.99
0.51
1002
998
500

1000.01
0.74
1002
998
485

1000.00
0.37
1002
999
510

1000.01
0.37
1004
996
450

can be measured, therefore, by calculating the difference in time

between each task release time for instant k and k 1, for k = 1
to n, where n is the number of release time samples.
The same test was conducted under four operational conditions:
1.
2.
3.
4.

Schedule execution alone;

Schedule execution with online FB monitoring;
Schedule execution with plant simulation and visualization;
Schedule execution with FB monitoring and plant simulation and
visualization.

The Table 3 presents the results obtained from executing the

FBSIMU on a Pentium Centrino Duo computer equipped with an
Intel T2400@1.83 GHz processor and 1.5 Gbytes RAM. The time unit
on Table 3 for the average period, standard deviation, maximum
and minimum values is milliseconds.
6.2. FBSIMU functional evaluation
The expected result from the first test with five users was meant
to verify:
- Which resources had not been foreseen for the ideal functioning
of the system?
- Which problems could appear during the system regular
operation?
- Does the proposed architecture permit a parallel remote access
to the FBSIMU for multiple users?
Summarizing, the test plan was created in order to provide
a scenario as close as possible to the real FBSIMU online use.
This scenario is composed of five users that execute their experiments concomitantly and independently, from five remote
stations. To reproduce the exact use of the tool, each user has
executed all the steps from the beginning. Firstly, each user
sent an e-mail to the administrator (this e-mail address is published at the Industrial Automation Laboratorys Moodle website:
http://lai.sel.eesc.usp.br/moodle/) requesting registration. With
the five accounts created, a confirmation e-mail was sent back to
the users. The next step for each user was to access the private area
at the Moodle website where the online FBSIMU is hosted, and then
access the FBSIMU itself. The FBSIMU web server correctly identified and informed the users connected at the access moment.
For each of the five instances of the FBSIMU remote panel
opened in five client workstations, the users executed simulations
as described on Section 3.4, saved logs and configurations files,
and logged out from the system. Since all experiments were saved,
the users would have many opportunities afterwards to access the
system again, loading the saved files and then continuing his/her
experiments with the saved configuration.

140

E.A. Mossin et al. / ISA Transactions 48 (2009) 132141

Table 4
Topic evaluated for grade (Students)
Topic

Grade (15)

Satisfaction
Easy to use
Without technical problems
Easy to access
Student Learning

4
3
5
3
4

Table 5
Topic evaluated for grade (Instructors)
Topic

Grade (15)

Satisfaction
Students interaction
Easy to evaluate the students
Easy to manage
Student Learning

4
4
3
5
4

6.3. Productivity and achievement evaluation

Once the tool functionality was successfully validated, the
next test evaluated productivity and achievement of users and
instructors. The 25 students accessed the online FBSIMU and
executed the same experiment detailed on the first test in this
section. A questionnaire was elaborated, and made available online
for the students, and another questionnaire was elaborated for the
instructor.
The consolidated results obtained from the students filled
questionnaires are shown in Table 4. The second evaluation involved the instructors feedback after completing the experiment.
Table 5 shows the consolidated results obtained through the analysis of the instructors questionnaire. For both tables the grade
represents: 1 (poor), 2 (not good), 3 (satisfactory), 4 (good) and 5
(excellent).
7. Analyses of the results
Related to the schedule table execution test results (Tables 2
and 3), the adoption of a hybrid simulation model on the FBSIMU,
composed of concurrent event-driven task and time-triggered
task, all inserted on a priority based preemptive execution, gave
the simulation platform a high degree of realism and a satisfactory
timing precision operation. However, it is noted that a theoretical
deterministic behavior is not possible to be obtained, as presented
on Table 3, because of the non-deterministic nature of the
Windows operational system, and because of the concurrence of
many other computer processes besides the simulation. In order to
interpret the results, it is necessary to consider that all the timing
calculation and the dispatching mechanisms are bounded in the
FBSIMU by the 1 ms resolution LabVIEW system clock. In spite of
the non-deterministic nature of the Windows operational system,
it is concluded that the simulation tool is able to reproduce the
real network fieldbus time behavior (time delays are satisfactory).
Thus, this test was successful.
In the FBSIMU functionality test (Section 6.2), the system
worked properly for all proposed test cases, therefore the online
platform functionality was validated. The conclusion is that the
tool stability is sufficiently good and this test was successful.
Considering the productivity and achievement evaluation
(Section 6.3) some facts can be noted about the results obtained
from the users (students and instructors) filled questionnaires.
In general, the users impression (Tables 4 and 5) are good (the
grade of most of the Topics is greater than 3) and characterizes
the general evaluation as successful. In addition, the proposed tool
reacted with robustness and stability in the tests.

Concerning the Topic Easy to use of students (Table 4), a

satisfactory grade was obtained. A better grade was not obtained
due to the FOUNDATION fieldbus configuration complexity. To
improve the system usability, a stronger help support could be
implemented in future versions of the FBSIMU.
Related to the Topic Easy to access of students (Table 4), a
better grade was not obtained due to LabVIEW Runtime Engine
installation when the user logs in the system. As cited before, to
enable running the online FBSIMU remotely, this engine must be
installed, and the download time to do that is substantial. The use
of JavaScript interfaces integrated to the LabVIEW web server is
a promising technology to overcome the use of Runtime Engines.
This solution is being investigated by the authors.
Analyzing the results obtained from the instructors filled
questionnaire (Table 5), it can be noticed that the methods for
student evaluation (Topic Easy to evaluate the students) need to
be improved to achieve an excellent grade. In the current version,
this evaluation was done exclusively through configuration files
and log files saved by the students.

8. Conclusions
The online system architecture can be considered simple to
manage and the use of a complete CMS framework gave the system
a valuable means to promote an efficient communication channel
between users and instructors.
Since the beginning of fieldbus protocols adopted by the
industrial community, there has been a large interest in research
related to the different aspects and functionalities of this
technology. Several research tools for simulation have been
developed to assist training programs and test routines. Besides its
low cost, when compared with real instruments and systems, an
additional advantage of simulation tools is the intrinsic flexibility
and safety, which allows the execution of a broad range of
experiments without security restrictions.
Due to the increasing presence of the Internet in and outside
industrial sites, an evident tendency for using remote access to
simulation tools or even to fieldbus systems with real instruments
is expected.
Considering the implementation architecture of the FBSIMU
simulation tool and its remote access, it has been demonstrated
that it is possible to consider realistic fieldbus simulations, in
an efficient way, by using a CMS system interacting with a local
simulation application in a remote clientserver model over the
Internet. The proposed interaction model between LabVIEW and
Moodle introduces certain complexities once two web servers
(Apache for Moodle and the LabVIEW web server for the FBSIMU
tool) must collaborate locally during simulations. The proposed
collaboration model for this application was successfully tested
and approved.
The satisfaction and the learning experience of the users are
positive results to be noted. This fact can be explained by the
high compatibility degree of the FBSIMU Function Blocks and
scheduling policy with the FF standards, and the intentional
similarity of its GUI to real fieldbus configuration software.
According to the result analysis section, this new tool is feasible
and can be applied for fieldbus automation systems training
purposes, considering the robustness and stability in the tests and
the positive feedback from users.
Acknowledgments
The authors gratefully acknowledge the Brazilian agency
FAPESP for the financial support received through the Kyatera
project, and the academic support and research structure from the
Engineering School of So Carlos - University of So Paulo. The
authors also acknowledge the important technical contributions
from Smar International Corporation.

E.A. Mossin et al. / ISA Transactions 48 (2009) 132141

References
[1] Berge J. Fieldbus for process control: Engineering, operation, and maintenance.
Research Triangle Park: ISA Books. 2002.
[2] Smar International Corporation. Fieldbus tutorial: A FOUNDATION fieldbus
technology overview. Sertozinho: Brazil. 2004.
[3] International organization for standardization. ISO/IEC 7498-1: Information
technology open systems interconnection basic reference model: The basic
model. Switzerland. CD-ROM. 1994.
[4] Cavalieri S, Di Stefano A, Mirabella O. Optimization of acyclic bandwidth
allocation exploiting the priority mechanism in the fieldbus data link layer.
IEEE Transactions on Industrial Electronics 1993;40(3):297306.
[5] Pop T, Eles P, Peng Z. Holistic scheduling and analysis of mixed time/eventtriggered distributed embedded systems. In: 10th international symposium
on Hardware/software codesign. 2002.
[6] Hong SH, Ko SJ. A simulation study on the performance analysis of the data
link layer of IEC/ISA fieldbus. Simulation 2001;76(2):10918.
[7] Wang Z, Yue Z, Chen J, Song Y, Sun Y. Realtime characteristic of FF
like centralized control fieldbus and its state-of-art. In: IEEE international
symposium on industrial electronics. 2002.
[8] Petalidis N, Gill DS. The formal specification of the fieldbus foundation link
scheduler in E-LOTOS. In: International conference on formal engineering
methods. 1998.
[9] Chen J, Wang Z, Sun Y. How to improve control system performance using FF
function blocks. In: IEEE international conference on control application. 2002.
[10] Ferreiro Garcia R, Vidal Paz J, Pardo Martinez XC, Coego Botana J. Fieldbus:
Preliminary design approach to optimal network management. In: IEEE
international workshop on factory communication systems. 1997.
[11] Fieldbus Foundation. FF-890-1.3: Foundation specification function block
application process, part 1. Austin, USA. 1999.
[12] Fieldbus Foundation. Foundation specification function block application
process Part 3: FF-892 FS1.4. Austin, USA. 1999.
[13] Fieldbus Foundation. Foundation specification function block application
process Part 5: FF-894 DPS0.95. Austin, USA. 1999.
[14] Brando D. Ferramenta de simulao para projeto, avaliao e ensino de redes
fieldbus, Doctorate thesis. Escola de Engenharia de So Carlos, USP. 2005.

141

[15] Pinotti Jr M, Brando D. A flexible fieldbus simulation platform for distributed

control systems laboratory courses. The International Journal of Engineering
Education 2005;21(6):10508. Dublin.
[16] Ljung L. System identification- theory for the user. Englewood Cliffs: Prentice
Hall; 1999.
[17] Luntz J, Messner W, Tilbury D. Web technology for controls education.
In: Proceedings of the IEEE conference on decision and control. 1997.
[18] Snchez J, Morilla F, Dormino S, Aranda J, Ruiprez P. Virtual control lab using
Java and Matlab: A qualitative approach. IEEE Control Systems Magazine 2002;
820.
[19] Liou S, Soelaeman H, Leung P. Distance learning power engineering laboratory.
Computer Applications in Power 1999;12(1):516.
[20] Ko CC, Chen BM, Chen J, Zhuang Y, Tan KC. Development of a webbased laboratory for control experiments on a coupled tank apparatus. IEEE
Transactions on Education 2001;44:7686.
[21] Clausen A, Spanias A, Xavier A, Tampi M. A Java signal analysis tool for signal
processing experiments. In: Acoustics, speech, and signal processing, ICASSP
98. Proceedings of the 1998 IEEE international conference, vol. 3. p. 184952.
[22] Qingcang YU, Chen B, Cheng HH. Web based control system design and
analysis. Control Systems Magazine, IEEE 2004;24(3):4557.
[23] Exel M, Gentil S, Michau F, Rey D. Simulation workshop and remote laboratory:
Two Web-based training approaches for control. In: Proceedings American
control conference, vol. 5. 2000. p. 346872.
[24] Buhler D, Kuchlin W, Grubler G, Nusser G. The virtual automation Lab-Web
based teaching of automation engineering concepts. Engineering of computer
based systems. In: Proceedings. Seventh IEEE international conference and
workshop. 2000. ECBS, p. 15664.
[25] Zeilmann RP, Gomes da Silva JJM, Bazanella AS, Pereira CE. Web-based control
experiments on a foundation fieldbus pilot plant. In: 5th IFAC international
conferences on fieldbus and their applications. 2003.
[26] Homepage, MOODLE. Free Support [Online]. Available at: http://moodle.org/
course/view.php?id=5.
[27] Irvine SE, Hein TL, Laughlin D. Different degrees of distance: The impact
of the technology-based instructional environment on student learning.
In: ASEE/IEEE Frontiers in Education Conference, 29, San Juan. Proceedings.
New York: IEEE; 1999. p. 13c-713c-12.