ISA Transactions 48 (2009) 132–141

Contents lists available at ScienceDirect

ISA Transactions

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

A fieldbus simulator for training purposesEduardo André Mossin, Rodrigo Palucci Pantoni ∗, Dennis BrandãoSchool Engineer of São Carlos - University of São Paulo, Brazil

a r t i c l e i n f o

Article history:Received 14 May 2008Received in revised form25 July 2008Accepted 29 July 2008Available online 30 August 2008

Keywords:Fieldbus automation systemsSimulatorLabView

a b s t r a c t

This article presents a fieldbus simulation platform and its remote access interface that enables awide range of experiments, where users can configure operation sequences and procedures typical ofFoundation Fieldbus systems. The simulation system was developed using LabVIEW, with requisites ofdeterministic execution, and a course management work frame web server called Moodle. The resultswere obtained through three different evaluations: schedule table execution, simulator functionalityand 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 andstability 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 controlindustry is nothing new. Since 1970, these devices have beenused first in direct digital control (DDC), and then in distributedcontrol system (DCS) or programmable logic controllers (PLC).The spread of microcontrollers’ technology in the 90’s enabledthe development of smart field devices, the main characteristic ofwhich 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 onthe plant, the next step is interconnecting all devices, andcreating an instrument network [2], nowadays called fieldbus,withrequisites of real time systems. Fig. 1 shows the basic architectureof a fieldbus network, composed of field devices, the fieldbuscommunication channel, the controller unit(s) and specializedengineering host stations.The great interest in this network model led several manufac-

tures to implement their own communication protocols, to en-able communication among their devices, and during the last twodecades, some criteria were defined in order to standardize thecommunication model, and enable communication among differ-ent 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), Profibusand 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).

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

Fieldbus (FF) protocol, one of the fieldbuses designed for typicalindustrial process control applications.The combination of two or more protocols on integrated

hybrid systems, as well as the use of such systems on process orequipment with fast dynamic responses, motivates the scientificcommunity to evaluate the performance of networked controlsystems (NCS). Such studies result in advances and optimization oftransmission media technologies, communication methods, newsmart 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, thelearning curve for this technology is slow, considering the largeamount of required professional background on the areas ofinstrumentation, software engineering anddigital communication.An important aspect when considering the learning process of thefieldbus technology is practical experience. There are considerablesafety and economical restrictions on the access of students,researchers and plant operators on training processes, to a realoperating industrial plant. Even bypassing the need for real plant,projecting and assembling a small plant destined only for trainingpurposes would certainly be considered an interesting option. Thisalternative leads aswell to certain restrictions, such as engineeringcosts, capital expenses and the low flexibility for executing abroad range of experiments and situations during the training ora 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 thecommunication of complete fieldbus networks, in order tounderstand, evaluate and practice its operation on networkconfiguration, device commissioning, plant start up, and systemoperation in automatic or manual modes.

ed.

E.A. Mossin et al. / ISA Transactions 48 (2009) 132–141 133

Fig. 1. Basic fieldbus network architecture.

Typically, simulation tools force the students, professionalsor researchers to go to a laboratory to execute their tests andchores. Due to the increasing availability of the Internet onacademic and industrial facilities, remote access through theInternet to simulators and plants shall be considered, because ofthe possibility to separate these resources from users.In fact, the use of simulations can be complementary to

traditional trainingmethods and facilities, or in a second approach,it can be considered and projected as flexible and realistic enoughto be used as a main training tool.This paper presents a web enabled simulation tool for net-

worked control systems, designed according to the FF specificationand aimed to be applied in industrial training programs and in aca-demic disciplines. The proposed simulation tool is named FBSIMU,and is focused on the user application layer, attending to requi-sites of realistic operation procedures and interfaces, and of realtime simulation dynamics. Its range of experience goes from field-bus system configuration and commission, to handling events andalarm conditions.This paper is organized in eight sections, including this

introduction. The next section introduces some characteristics ofthe FOUNDATION Fieldbus protocol and application process, usedas a model to design the FBSIMU architecture. This architectureand the resulting simulation platform are explained later on thesection ‘‘FBSIMUArchitecture’’. The description of a typical trainingapplication 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 automa-tion in a broader sense, and control systems disciplines.The Internet access mechanism and the client–server model

of cooperation proposed for the remote use of the FBSIMU arepresented 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 theresults are discussed in the Section 7.Finally, the authors discuss new perspectives for development

and application of the FBSIMU tool, and the identification of trendson distance training models, dedicated to industrial automationand distributed control systems.

2. The Foundation Fieldbus protocol

The term FOUNDATION Fieldbus indicates the protocol speci-fied by the Fieldbus Foundation. It is a digital, serial, bidirectional,and distributed protocol, which interconnects field devices such assensors, actuators and controllers. Basically, this protocol can be

classified as a LAN (Local Area Network) for instruments used inprocess and industrial automation,with the ability to distribute thecontrol application through a network.This protocol is based on the ISO/OSI (International Organi-

zation for Standardization/Open System Interconnection) seven-layer reference model [3]. Although being based on the ISO/OSImodel, the FF does not use the network layer, the transport layer,the section layer, nor the presentation layer, because it is restrictedto local applications. The entire network structure of the FF concen-trates on the physical layer, the data link layer (DLL) and the appli-cation layer. Besides these three implemented layers, the protocoldefines 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/sbaud rate with Manchester bit codification over a bus poweredchannel. The network topology configuration is flexible: it istypically configured with a trunk and several spurs, attendingcertain physical and electrical limitations regarding maximumlength and number of transmitters.The DLL carries the transmission control of all messages on

the fieldbus and its protocol grants to the FF network temporaldeterminism. The communication is based on a master–slavemodel with a central communication scheduler (master), namedLink Active Scheduler or LAS. This node performs the mediumaccess control (MAC).Two types of DLL layer are standardized: Basic and LinkMaster.

A Basic DLL transmitter does not have LAS capabilities, it operatespassively as a communication slave. A LinkMaster DLL transmitter,on the other hand, can execute LAS functions and thus, if the activeLAS 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 (un-scheduled) background data. These two communication policiesshare the physical bus, but they are respectively segmented incyclic time slots or periods. In the scheduled communication pe-riod, most process variables generated by periodic processes aretransmitted cyclically according to a static global schedule tableloaded on the LAS node. This cyclic transmission mode has higherpriority 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 bedelivered before the next data is available. This type of periodicdata 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) 132–141

not directly related to the control loop cycles, but to configura-tion actions and data supervision efforts. The unscheduled trans-missions are dispatched under a token pass scheme. A token thatcirculates among all active nodes on the bus is used in FF protocol.Once a transmitter receives the token, it is granted the right to sendpending aperiodicmessageswith aminimumpriority for a specifictime period.Non periodic (or event-triggered) processes are initiated as

soon as specific events are noted [5]. The event-triggered processesare unpredictable and usually related to alarm notifications,configuration data and user commands as cited before. Althoughacyclic traffic is less frequent than the cyclic one, the acyclic datashould also be delivered prior to a certain time deadline, accordingto the system requirements.For a description of theMACoperation onboth cyclic and acyclic

phases, refer to [6–8].The FF User Layer is directly related to the process automation

tasks themselves, and it is based on distributed control ormonitoring strategies of Function Blocks. Function Blocks (FBs)are User Layer elements that encapsulate basic automationfunctions and consequentlymake the configuration of a distributedindustrial application modular and simplified [9]. Distributedamong the transmitters, the FBs have their inputs and outputslinked to other blocks in order to perform distributed closedcontrol loop schemes.When blocks from different transmitters arelinked together, a remote link is configured andmapped to a cyclicmessage. Considering that all cyclic messages should be releasedin a predetermined instant defined on a schedule table, and thatthey carry data generated by the FBs, it is adequate to synchronizethe execution of the FB set on the system with the referred cyclictransmissions schedule table. This solution leads to the concept ofjoint scheduling [10].The Foundation Fieldbus standardized a set of ten basic

function blocks [11], a complementary set of eleven advancedcontrol blocks [12], and a special flexible function block intendedto be fully configurable, i.e., internal logic and parameter, bythe user [13]. The standard and advanced block sets providemathematical and engineering calculations necessary to configuretypical industrial control loop strategies, while the flexiblefunction block can be applied to custom or advanced controls or tocomplex interlocking logics based on ladder nets. It is important tostate, however, that the standard is open at this point, permittingthe integration of ‘‘user-defined’’ custom function blocks in orderto enhance the capabilities of FF control system, and make theintegration of novel control techniques possible.

3. FBSIMU architecture

The basic concept of the FBSIMU architecture is to map eachFunction Block, as well as the plant, in an independent LabVIEWapplication, also named Virtual Instrument (VI). The configurationof the whole system is centralized in the FBSIMU.CONF module.This module’s front panel (GUI) is inspired by commercial fieldbusconfiguration tools.As mentioned before, the FBSIMU is focused on the function

block application layer and it is composed exclusively of softwareaccording to a modular and extensible architecture. The simulatorwas developed in LabVIEW using the G graphical programminglanguage, ‘‘native’’ language in this environment. Each FBSIMUmodule or software unit simulates an element or a structure of areal FOUNDATION Fieldbus system [14].

3.1. Function Block simulation

The Function Block modules are programmed into the FBSIMUaccording to the FF specifications directions and, consequently, theusage and configuration of a simulated control loop on the FBSIMUenvironment 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 facilitatesthe development and integration of standard and custom FBs tothe system. These functions encapsulate different FF calculationsand data type manipulations necessary to build Function Blocks,configuring a ‘‘LabVIEW Foundation Fieldbus Tool Kit’’. A FunctionBlock seed module is also used to facilitate the process ofdeveloping and integrating new projects. The seed has the wholeFB module structure (an empty structure) and directions toproceed with a FB project from the design to the final testprocedures.Each FB module is built as two different versions that share the

same FB core: stand-alone and process. The stand-alone FBs areexecuted by user commands and controlled by its front panel. Itsexecution can be performed independently of any other module,so the user is able to test the FB and simulate its operationunder a controlled condition of inputs and outputs. The graphicaluser interface is intuitive and enables the user to execute the FBcontinually 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 uniqueidentification and its operation is controlled by the user throughthe following commands:

- FB_Read: this service allows the value associated with a blockparameter to be read.- FB_Write: this confirmed service allows the value associatedwith a block parameter to be written.- FB_Exec: this service triggers the block algorithm to beexecuted.- FB_Reset: this service allows default values associated with allblock parameters to be written.

Process FBs do not have front panels; they are instantiated bythe FBSIMU.CONF in each simulation process. The communicationsbetween process FBs and the FBSIMU.CONF are performedprogrammatically and dynamically by the LabVIEW function ‘‘Callby Reference Node’’. It is important to note that the industrialtransmitters are not considered in the FBSIMU architecture,i.e., function blocks are instantiated on the simulation withoutbeing allocated in specific ‘‘virtual’’ transmitters. The FBSIMU.CONFmodule front panel for fieldbus configuration is shown in Fig. 2.

3.2. Physical plant simulations

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 theFBSIMU.CONF and simulates the controlled plant. The adopted ARXstructure is represented by Eq. (1), where k is the discrete timeinstant, Y is the output vector,U is the input vector, i is the numberof MIMO plant inputs and outputs, na is the number of outputregressors, and nb is the number of input regressors. In the currentversion, i is set to 1 (one) to reflect a SISO model.

Yi×1 (k) =na∑s=1

Asi×i ⊗ Yi×1 (k− s)+nb∑s=1

Bsi×i ⊗ Ui×1 (k− s) . (1)

E.A. Mossin et al. / ISA Transactions 48 (2009) 132–141 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 dynamicmatrixesA and B. Itmust be observed that the number of regressorslimits the model dynamic order – in the actual version it is limitedto third order systems – and that all regressors must be initializedprior to starting the simulation. A white noise generator functionadds a simulated acquisition noise to each plant output boundedby 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’ BodeMagnitude Chart, Pole-Zero Map, Root Locus Graph and the StepResponse are instantly presented on the front panel. The thirdorder system is composed of a first order system in series with asecond 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 theFBSIMU.CONF module front panel for plant configuration.

3.3. Simulation architecture

The proposed execution model for the fieldbus simulation onFBSIMU can be considered hybrid, because some tasks are event-driven, while other tasks are time-triggered. All tasks related tothe user interface are event-driven, they are executed after a useraction, 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 FBsare time-triggered.Due to the fact that all tasks are performed on a single

microprocessor, they are, naturally, concurrent. The proposedsolution for preventing unexpected delays of time-triggeredtasks (considered critical) due to executing event-driven tasks(considered non-critical) is adopting priority levels for each taskand preemptive execution mode.

136 E.A. Mossin et al. / ISA Transactions 48 (2009) 132–141

Table 1FBSIMU task set

Module Priority Execution Timeout Determinism

GUI & User commands Low–low Event driven 1 s NoFB schedule High–high Time triggered according to the schedule table No YesPlant execution High Periodic with configurable period No YesOnline FB parameters monitoring Low Periodic with period= 500 ms No Yes

Fig. 4. FBSIMU block list.

Fig. 5. FBSIMU schedule table.

In the preemptive executionmode, a higher priority task that isready to execute preempts all lower priority tasks, which are alsoready 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 rangeof FBSIMU experiments, where users can exploit the effect ofimportant communication parameters and configurations found inindustrial FF systems. Practical experiments consist of comparinggiven simulated fieldbus system performances over differentoperation conditions. The results can be analyzed via log files orgraphically on charts.For typical simulation training, the FB control strategy should

be defined. Then, the period of the macrocycle must be setin milliseconds, and all the release times (in milliseconds) ofeach FB execution and FB link must be defined regarding themacrocycle start instant. Figs. 4 and 5 present an example of theseconfigurations 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 supportthe 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 simulationmodule, as represented inFig. 7.The connection between an Analog Output block (AO) and

the plant input (manipulated variable — MV) and the connectionbetween the plant output (primary value — PV) and the AnalogInput block (AI) are configured by the user for close loopexperiments. Alternatively, the usermay connect only the plant PV

to the AI block for an open loop simulation, or manually load theplant 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 possibleto monitor the parameter table with online parameter values andregister the parameters on text files for further analysis.With the FBSIMU architecture, the FF operation scenarios

can be configurable and different sequences of practice trainingcan be defined to embrace fundamental concepts of fieldbuscontrol systems, as well as practical situations of alarms orevents handling. This characteristic is considered importantby the authors, because most of the traditional pilot plantsequipped with fieldbus instrumentation offer just one or a fewscenarios, whereas a full sequence of practice experiments shouldbe based on it. Thus, the use of a simulated fieldbus systemenables a flexible evaluation of the contribution and effect of thecommunication protocol on the overall system dynamics, whichis an impossible goal considering that, in pilot plants equippedwith real instrumentation, most communication configurationsare fixed and, in most cases, inaccessible to end-users.

4. On-line laboratories in automation and industrial controlarea

It is possible to identify three distinct approaches in theliterature associated with distance learning methodologies, usedin 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 todynamic simulators for control loops and, eventually, for industrialinstruments. The third approach, currently in disuse, is based onon-line tutorials, where users have some information about asubject but do not have interactive methods of learning. A simpleactivity, showed in [17], can be performed through a tutorialwherea user copies commands from a web page and pastes them inMATLAB. After executing the application, the analysis of the resultsis 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 thesimulation method is that it allows the user to conduct anytype of experiment without security restrictions or concerns. Adisadvantage of simulation systems is that it does not provide amore 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 andSection 4.2 shows examples of remote access to simulations. Then,Section 4.3 shows the examples of remote laboratories whichprovide 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 composedof an environment for distance operation of a real testing plantthrough the Internet. The plant, an inverted pendulum, is locatednear the server machine. The system was developed with thepurpose of not showing the physical plant characteristics to theuser, and therefore, the system can be easily adapted to otherplants located in this laboratory. An important characteristic of this

E.A. Mossin et al. / ISA Transactions 48 (2009) 132–141 137

Fig. 6. FB parameter table.

Fig. 7. Plant simulation module.

work is that professors can add different experiments by simplyediting the configuration file.Also exemplifying didactic experiences through remote access

to real plants, a system that allows the users to access instrumentsthrough the web is described in [19]. In this system, instructorscan configure equipments even during a class. The systemarchitecture is composed of a server machine connected todifferent instruments (sensors, actuators, motors, power supplies),and equipment control is performed by a LabVIEW application.With remote access through the web, the instructor connects tothe LabVIEW to modify different instruments’ parameters, thushaving the ability to take different directions in his/her classes. Inthis system, the user has limited access to some parameters due tosecurity reasons.In [20], the remote access to a laboratory with four types of

control loops (manual and PID control, space state algorithms andfuzzy logic) was implemented. Also, in this laboratory, it is possibleto remotely access a platform where researchers execute tests oncontrol algorithms. The system supplies images and sounds fromthe laboratory through a camera built in a mobile platform. Theplant used in the experiment consists of coupled tanks.

4.2. Remote access to simulation tools

Experiments that involve tutorial sections, theoretical exercisesand experiments in simulated plants have been explored througha 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 clientmachinemusthave the MATLAB software installed locally.Another example is a tool that simulates a Digital Signal

Processing (DSP) laboratory [21]. The laboratory has five exerciseswhich cover Z-Transform theory, Frequency Response, Fouriertransform 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 analysisunder the classic and modern theories was created [22]. The toolsupports models represented in both state space and transferfunctions notations. The user, using a web browser, can choose theproject and analysis methods of a controller, specify the type ofcontrol systemand configure its parameters. Data is sent to a serverfor 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 pointchanges and disturbance, are also explored [23]. The author affirmsthat simulations are excellent for theory assimilation, but theycannot substitute a real experiment in the laboratory.

4.3. Distance learning of Fieldbus protocols

Beyond control theory, some cases of distance learning explorethe teaching of fieldbus protocols. An example of a virtuallaboratory focusing on the CAN protocol (Controller Area Network)can be cited [24]. This laboratory, called Virtual Automation Lab, isan interactive tool for distance learning of CAN protocol operation.The tool can be used in two ways: first, as a real laboratoryconnected to the Internet using a remote interface, where theuser operates a real device and observes characteristics of fieldbusnetworks, such as communication delays, fails, etc; and second,through simulations that allow users to get used to this type offieldbus system before handling real instruments. The experimentuses a PC, one web cam, some intelligent transmitters operatingwithCANopenprotocol and aCAN interface board. The stages of thecourse cover motivation, group objectives, educational objectives,general vision and exercises. To complete an exercise, the devicesmust be available for use (only one user can access the devices pertime) and some security restrictions must be considered.

138 E.A. Mossin et al. / ISA Transactions 48 (2009) 132–141

Fig. 8. FBSIMU On-line architecture.

Using another fieldbus protocol, an experimental practicewith remote access to a pilot plant explores the basics of theFOUNDATION Fieldbus protocol [25]. This remote access allowsthe user to execute experiments and supervise a pilot plant.This system is also used as a platform for industrial automationresearch. The adopted pilot plant consists of three coupled tanks,flow pumps and five control valves used to manipulate theoutflows of liquids in the system. It is possible to configure severalcontrol strategies using the tank level variables, outflows andtemperatures. The system architecture follows the client–servermodel. The client is an applet that communicates with theweb server using sockets. The SCADA software is installed onthe server with an OPC interface, which receives informationfrom the fieldbus network. The SCADA software creates a webpage with all the necessary process data and makes themavailable to the remote user. The system has also a web camfor visual tracking of the plant dynamics. As auxiliary functionsto the training procedures, the system contains user accesscontrol, a sub-system for scheduling experiments, a method formonitoring the duration of practical sections and a configurationarea in which users can set some parameters from the controlsystem. Since the system is composed of a real pilot plant,experiments cannot be executed bymore than oneuser at the sametime.

5. Online FBSIMU

Aiming to provide the flexibility for users’ access to fieldbuslearning systems and to follow the distance learning tendency, anonline version of the FBSIMU platform is described in this section.The online version of the simulator is based on the client–server

model. The server executes several instances of the FBSIMUand theclients are the users’ computers.On the proposedmodel, two additional functionswere added to

the local scheme simulation, described on the previous sections, inorder to coordinate the remote transactions. The main additionalfunction is related to user access control. The other functionalityis an online questionnaire that registers information related to theusers’ learning process for future efficiency analysis of the remotemodel.

5.1. Server side

The FBSIMU server is composed of two web servers. The firstserver is responsible for user access control, forums, links, andthe questionnaire. This server was developed through a CourseManagement System (CMS), a configurable framework,whose goalis to organize and speed up the creation,management, distributionand publication of information in remote courses context. The CMSoffers features that allow the web master to execute the wholecontentmanagement process fromweb browsers, in a remoteway.Moreover, the CMS offers a framework with some features alreadyimplemented, 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] wasused in the on-line FBSIMU implementation.Moodle is an open-source software licensed under GNU GPL

(General Public License), maintained and revised by a communityof users and developers. The software is developed with the PHPscript language; it stores data in aMySQLdatabase anduses Apacheas its web server.The second web server deals with remote access to the FBSIMU

environment itself. This access is performed through a native webserver embedded in the LabVIEW. It is activated by the FBSIMUmodules, i.e., the FBSIMU VI’s (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 toinstall the LabView Runtime Engine in the client machine. Thissoftware can be downloaded from the National Instruments HomePage or the LAI Home Page (http://lai.sel.eesc.usp.br/moodle/).Considering that LabVIEW andMoodleworkwith different web

servers (Moodle uses Apache while LabVIEW uses its own webserver), 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 bothMoodle and LabVIEW. Fig. 8 shows the basic architecture for thissystem.Following this architecture, steps i, ii and iii illustrate the

communication flow between the client workstation and theserver:

(i) Moodle validates the user who tries to log in the system. Atthis moment, the user may or may not have permission toaccess the FBSIMU.

E.A. Mossin et al. / ISA Transactions 48 (2009) 132–141 139

(ii) User with permission accesses the FBSIMU link. At thismoment, the system executes a PHP code that controls whichusers are operating the system. This information is stored inthe database. After executing the validation, another PHP codegenerates a HTML file that will be used on the access of theFBSIMU instance. Generated such archive, the access addressis returned transparently to the client workstation.

(iii) This address is a response to a PHP call, and when this valueis received by the client workstation, a new Web navigatorwindowwill open, pointing to this address. Then, the accessedHTML will link the client workstation to the FBSIMU instance.

5.2. Client side

On the client side, the first web page shows a brief descriptionof the experiment and the link for the user log-in page. This webpage is provided by the Moodle module through the Apache webserver.After the user logs on the system, he/she can access the FBSIMU

tool. Access will be provided by the LabVIEW embedded webserver.Besides the FBSIMU access, the system proposes a question-

naire, which registers information related to the users’ learningprocess 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 timingprecision, robustness and stability of the FBSIMU running over theInternet.On the schedule table execution test, a static schedule tablewas

configured and, based on this table, the test was executed underfour simulation operational conditions in order to verify the timingprecision of the schedule table dispatchmechanism, themost timecritical process in the simulator.On the FBSIMU functionality test, the robustness and the

stability of the FBSIMU online version were tested, when accessedby a group of five concomitant users. This group of studentsexecuted 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 achieve-ment on the learning process with the use of the FBSIMU ona remote scheme, a class of 25 undergraduate industrial au-tomation students executed a regular FBSIMU experiment andanswered a questionnaire. Another questionnaire was used toevaluate the instructor’s impression about the tool (produc-tivity and achievement test). These questionnaires are pub-lished at the Industrial Automation Laboratory’s 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 theIndustrial Automation Laboratory.For this test, a PID Control strategy composed of three Function

Blocks (AI-PID-AO) was configured, and a schedule table wasproposed for its execution. The schedule table and the macrocycleperiod 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

Table 2Schedule table configuration

Task Release time (ms)

AI 0PID 300AO 600AI.OUT→ PID.IN 100PID.OUT→ AO.CAS_IN 400PID.BKCAL_OUT→ AO.BKCAL_IN 700Macrocycle period 1000

Table 3Experimental timing measurements

Cond. 1 Cond. 2 Cond. 3 Cond. 4

Average period 999.99 1000.01 1000.00 1000.01Standard deviation 0.51 0.74 0.37 0.37Max. value 1002 1002 1002 1004Min. value 998 998 999 996Number of samples 500 485 510 450

can be measured, therefore, by calculating the difference in timebetween each task release time for instant ‘‘k’’ and ‘‘k−1’’, for k = 1to n, where ‘‘n’’ is the number of release time samples.The same test was conducted under four operational condi-

tions:1. Schedule execution alone;2. Schedule execution with online FB monitoring;3. Schedule execution with plant simulation and visualization;4. Schedule execution with FB monitoring and plant simulation andvisualization.

The Table 3 presents the results obtained from executing theFBSIMU on a Pentium Centrino Duo computer equipped with anIntel T2400@1.83GHzprocessor and1.5Gbytes RAM. The timeuniton Table 3 for the average period, standard deviation, maximumand minimum values is milliseconds.

6.2. FBSIMU functional evaluation

The expected result from the first testwith five userswasmeantto verify:- Which resources had not been foreseen for the ideal functioningof the system?- Which problems could appear during the system regularoperation?- Does the proposed architecture permit a parallel remote accessto the FBSIMU for multiple users?

Summarizing, the test plan was created in order to providea scenario as close as possible to the real FBSIMU online use.This scenario is composed of five users that execute their ex-periments concomitantly and independently, from five remotestations. To reproduce the exact use of the tool, each user hasexecuted all the steps from the beginning. Firstly, each usersent an e-mail to the administrator (this e-mail address is pub-lished at the Industrial Automation Laboratory’s Moodle website:http://lai.sel.eesc.usp.br/moodle/) requesting registration. Withthe five accounts created, a confirmation e-mail was sent back tothe users. The next step for each user was to access the private areaat theMoodlewebsitewhere the online FBSIMU is hosted, and thenaccess the FBSIMU itself. The FBSIMU web server correctly identi-fied 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 simulationsas 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 thesystem again, loading the saved files and then continuing his/herexperiments with the saved configuration.

140 E.A. Mossin et al. / ISA Transactions 48 (2009) 132–141

Table 4Topic evaluated for grade (Students)

Topic Grade (1–5)

Satisfaction 4Easy to use 3Without technical problems 5Easy to access 3Student Learning 4

Table 5Topic evaluated for grade (Instructors)

Topic Grade (1–5)

Satisfaction 4Students interaction 4Easy to evaluate the students 3Easy to manage 5Student Learning 4

6.3. Productivity and achievement evaluation

Once the tool functionality was successfully validated, thenext test evaluated productivity and achievement of users andinstructors. The 25 students accessed the online FBSIMU andexecuted the same experiment detailed on the first test in thissection. A questionnairewas elaborated, andmade available onlinefor the students, and another questionnaire was elaborated for theinstructor.The consolidated results obtained from the students’ filled

questionnaires are shown in Table 4. The second evaluation in-volved the instructor’s feedback after completing the experiment.Table 5 shows the consolidated results obtained through the anal-ysis of the instructor’s questionnaire. For both tables the graderepresents: 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 2and 3), the adoption of a hybrid simulation model on the FBSIMU,composed of concurrent event-driven task and time-triggeredtask, all inserted on a priority based preemptive execution, gavethe simulation platform a high degree of realism and a satisfactorytiming precision operation. However, it is noted that a theoreticaldeterministic behavior is not possible to be obtained, as presentedon Table 3, because of the non-deterministic nature of theWindows operational system, and because of the concurrence ofmany other computer processes besides the simulation. In order tointerpret the results, it is necessary to consider that all the timingcalculation and the dispatching mechanisms are bounded in theFBSIMU by the 1 ms resolution LabVIEW system clock. In spite ofthe non-deterministic nature of the Windows operational system,it is concluded that the simulation tool is able to reproduce thereal 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 onlineplatform functionality was validated. The conclusion is that thetool 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 obtainedfrom the users’ (students and instructors) filled questionnaires.In general, the users’ impression (Tables 4 and 5) are good (thegrade of most of the Topics is greater than 3) and characterizesthe general evaluation as successful. In addition, the proposed toolreacted with robustness and stability in the tests.

Concerning the Topic ‘‘Easy to use’’ of students (Table 4), asatisfactory grade was obtained. A better grade was not obtaineddue to the FOUNDATION fieldbus configuration complexity. Toimprove the system usability, a stronger help support could beimplemented 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 Engineinstallation when the user logs in the system. As cited before, toenable running the online FBSIMU remotely, this engine must beinstalled, and the download time to do that is substantial. The useof JavaScript interfaces integrated to the LabVIEW web server isa promising technology to overcome the use of Runtime Engines.This solution is being investigated by the authors.Analyzing the results obtained from the instructor’s filled

questionnaire (Table 5), it can be noticed that the methods forstudent evaluation (Topic ‘‘Easy to evaluate the students’’) need tobe improved to achieve an excellent grade. In the current version,this evaluation was done exclusively through configuration filesand log files saved by the students.

8. Conclusions

The online system architecture can be considered simple tomanage and the use of a complete CMS framework gave the systema valuable means to promote an efficient communication channelbetween users and instructors.Since the beginning of fieldbus protocols adopted by the

industrial community, there has been a large interest in researchrelated to the different aspects and functionalities of thistechnology. Several research tools for simulation have beendeveloped to assist training programs and test routines. Besides itslow cost, when compared with real instruments and systems, anadditional advantage of simulation tools is the intrinsic flexibilityand safety, which allows the execution of a broad range ofexperiments without security restrictions.Due to the increasing presence of the Internet in and outside

industrial sites, an evident tendency for using remote access tosimulation tools or even to fieldbus systems with real instrumentsis expected.Considering the implementation architecture of the FBSIMU

simulation tool and its remote access, it has been demonstratedthat it is possible to consider realistic fieldbus simulations, inan efficient way, by using a CMS system interacting with a localsimulation application in a remote client–server model over theInternet. The proposed interaction model between LabVIEW andMoodle introduces certain complexities once two web servers(Apache for Moodle and the LabVIEW web server for the FBSIMUtool) must collaborate locally during simulations. The proposedcollaboration model for this application was successfully testedand approved.The satisfaction and the learning experience of the users are

positive results to be noted. This fact can be explained by thehigh compatibility degree of the FBSIMU Function Blocks andscheduling policy with the FF standards, and the intentionalsimilarity 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 trainingpurposes, considering the robustness and stability in the tests andthe positive feedback from users.

Acknowledgments

The authors gratefully acknowledge the Brazilian agencyFAPESP for the financial support received through the Kyateraproject, and the academic support and research structure from theEngineering School of São Carlos - University of São Paulo. Theauthors also acknowledge the important technical contributionsfrom Smar International Corporation.

E.A. Mossin et al. / ISA Transactions 48 (2009) 132–141 141

References

[1] Berge J. Fieldbus for process control: Engineering, operation, andmaintenance.Research Triangle Park: ISA Books. 2002.

[2] Smar International Corporation. Fieldbus tutorial: A FOUNDATION fieldbustechnology overview. Sertãozinho: Brazil. 2004.

[3] International organization for standardization. ISO/IEC 7498-1: Informationtechnology – open systems interconnection – basic referencemodel: The basicmodel. Switzerland. CD-ROM. 1994.

[4] Cavalieri S, Di Stefano A, Mirabella O. Optimization of acyclic bandwidthallocation exploiting the priority mechanism in the fieldbus data link layer.IEEE Transactions on Industrial Electronics 1993;40(3):297–306.

[5] Pop T, Eles P, Peng Z. Holistic scheduling and analysis of mixed time/event-triggered distributed embedded systems. In: 10th international symposiumon Hardware/software codesign. 2002.

[6] Hong SH, Ko SJ. A simulation study on the performance analysis of the datalink layer of IEC/ISA fieldbus. Simulation 2001;76(2):109–18.

[7] Wang Z, Yue Z, Chen J, Song Y, Sun Y. Realtime characteristic of FFlike centralized control fieldbus and it’s state-of-art. In: IEEE internationalsymposium on industrial electronics. 2002.

[8] Petalidis N, Gill DS. The formal specification of the fieldbus foundation linkscheduler in E-LOTOS. In: International conference on formal engineeringmethods. 1998.

[9] Chen J, Wang Z, Sun Y. How to improve control system performance using FFfunction 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: IEEEinternational workshop on factory communication systems. 1997.

[11] Fieldbus Foundation. FF-890-1.3: Foundation specification function blockapplication process, part 1. Austin, USA. 1999.

[12] Fieldbus Foundation. Foundation specification function block applicationprocess Part 3: FF-892 – FS1.4. Austin, USA. 1999.

[13] Fieldbus Foundation. Foundation specification function block applicationprocess Part 5: FF-894 – DPS0.95. Austin, USA. 1999.

[14] Brandão D. Ferramenta de simulação para projeto, avaliação e ensino de redesfieldbus, Doctorate thesis. Escola de Engenharia de São Carlos, USP. 2005.

[15] Pinotti Jr M, Brandão D. A flexible fieldbus simulation platform for distributedcontrol systems laboratory courses. The International Journal of EngineeringEducation 2005;21(6):1050–8. Dublin.

[16] Ljung L. System identification- theory for the user. Englewood Cliffs: PrenticeHall; 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] Sánchez J, Morilla F, Dormino S, Aranda J, Ruipérez P. Virtual control lab usingJava andMatlab: A qualitative approach. IEEE Control SystemsMagazine 2002;8–20.

[19] Liou S, SoelaemanH, Leung P. Distance learning power engineering laboratory.Computer Applications in Power 1999;12(1):51–6.

[20] Ko CC, Chen BM, Chen J, Zhuang Y, Tan KC. Development of a web-based laboratory for control experiments on a coupled tank apparatus. IEEETransactions on Education 2001;44:76–86.

[21] Clausen A, Spanias A, Xavier A, Tampi M. A Java signal analysis tool for signalprocessing experiments. In: Acoustics, speech, and signal processing, ICASSP’98. Proceedings of the 1998 IEEE international conference, vol. 3. p. 1849–52.

[22] Qingcang YU, Chen B, Cheng HH. Web based control system design andanalysis. Control Systems Magazine, IEEE 2004;24(3):45–57.

[23] ExelM, Gentil S,Michau F, ReyD. Simulationworkshop and remote laboratory:Two Web-based training approaches for control. In: Proceedings Americancontrol conference, vol. 5. 2000. p. 3468–72.

[24] Buhler D, Kuchlin W, Grubler G, Nusser G. The virtual automation Lab-Webbased teaching of automation engineering concepts. Engineering of computerbased systems. In: Proceedings. Seventh IEEE international conference andworkshop. 2000. ECBS, p. 156–64.

[25] Zeilmann RP, Gomes da Silva JJM, Bazanella AS, Pereira CE. Web-based controlexperiments on a foundation fieldbus pilot plant. In: 5th IFAC internationalconferences 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 impactof 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-7–13c-12.