OPC-DB Link for the Management of NewSystems in a Remote Laboratory

Manuel Domınguez, Serafın Alonso, Juan J. FuertesMiguel A. Prada, Antonio Moran, Pablo Barrientos

SUPPRESS research group, Esc. de Ing. Industrial e Informatica,Campus de Vegazana s/n, 24071, Leon, Spain

(e-mail: author@unileon.es).

Abstract: The remote laboratories are proven tools for technological training. In theselaboratories, the students interact with a real system through the Internet, as if they werephysically in front of the system. When a remote laboratory is developed, many technicaldifficulties arefound, mainly with respect to the links between the different elements suchas physical system, database and clients. In this sense, it is necessary to make an effort tostandardize the implementation of the links. In this paper, we propose a standard applicationto communicate the physical systems and the database. This middleware, called OPC-DB, usesOPC (OLE for Process Control) for communication with control systems and has been developedin LabVIEW. The software can be easily reused in different laboratories by means of a database.

Keywords: Web-based laboratories, remote monitoring, control education, laboratorymanagement system, data exchange, OPC-DB link, OPC protocol.

1. INTRODUCTION

A complete learning experience in engineering educationshould include experimentation with systems to introduceprofessional practice and skills, support analytical con-cepts and increase the involvement of the students (Lind-say and Good, 2005). Remote laboratories have proven tobe effective educational tools in engineering, with compa-rable results to traditional on-site labs (Nickerson et al.,2007). Indeed, they provide additional advantages, suchas their flexibility, which is appealing for the students.The remote laboratories also enable sharing the scarcelyavailable equipment. This is a relevant issue because ed-ucation on technological subjects often requires the useof complex and expensive equipment. As a result, thedevelopment of virtual and remote laboratories in thefield of automatic control has advanced significantly inthe last years (Guzman et al., 2010; Leva and Donida,2008). The Remote Laboratory of Automatic Control ofthe University of Leon (LRA-ULE) (Domınguez et al.,2011)is a laboratory oriented to research and educationwith a focus on real industrial equipment.

The experience has shown that, in order to provide educa-tional value with a reasonable use of resources, a remotelaboratory needs to be more than a working prototype andensure certain standards in manageability, extensibility,security and accessibility (Garcıa-Zubia et al., 2009). Itis necessary to recognize the importance of software toprovide the performance and scalability needed to ensureits educational usefulness. Convenient approaches will alsoalleviate the workload needed to create new experimentsor set up new physical devices. For that reason, researchin the field of remote laboratories is progressively focusingon hardware and software solutions that address usualproblems or provide general frameworks.

The traditional architecture of remote laboratories is N-tier, also a usual structure in general web development(Eckerson, 1995). Between the client application that runsin the computer of the user and the physical systems, thereis a number of layers that provide different services suchas authentication, scheduling, data logging, additional ed-ucational content or security. The communication betweenadjacent layers is a key issue because its implementationshould balance effectiveness, flexibility and rapid develop-ment. Usually, these aims is met through the provision ofinterface libraries that can be used by the applications tocommunicate transparently. These application program-ming interfaces (API) often make use of state-of-the-arttechnologies such as web services.

In the field of industrial automation, there is a standardcalled OPC (Object Linking and Embedding for ProcessControl) for the communication of real-time plant databetween control devices from different manufacturers. Thispaper proposes leveraging the OPC standard to communi-cate between the industrial plants and the upper manage-ment layers. It presents a middleware based on OPC thatacts as interface between the industrial equipment and themiddle layer of the LRA-ULE platform. Section 2 describesthe state of the art regarding the architecture of remotelaboratories and the solutions proposed to communicatebetween their layers. Section 3 presents the proposedapproach and its implementation. After that, section 4explains the usage of the middleware in the LRA-ULEplatform. Finally, the conclusions are discussed in 5.

2. ARCHITECTURES AND COMMUNICATIONAPPROACHES IN REMOTE LABORATORIES

The field of remote laboratories has achieved a certainlevel of maturity. Nowadays, several platforms provide

Preprints of the 19th World CongressThe International Federation of Automatic ControlCape Town, South Africa. August 24-29, 2014

Copyright © 2014 IFAC 9715

much more than the simple remote control/monitoringof a physical system through the Internet. They provideresource-efficient solutions oriented to achieve aims suchas scalability, platform independence, security and acces-sibility. There are nevertheless two main goals that anyeffective remote laboratory must address. One is the abil-ity of connecting heterogeneous physical systems easily.The other one is to alleviate the workload of the websiteadministrators, who are sometimes faculty and need tospend their time developing educational content instead ofperforming tasks such as user management, new systemsconfiguration, etc. In order to provide the required levelof manageability, the approaches use multi-tier architec-tures, centralize some core services and use standardizedinterfaces for communication.

In this section, some relevant examples of remote labora-tories, which are not constrained to the field of control en-gineering, are presented. It can be seen that some of themmanage the communication with the system completely,storing data and controlling the interaction, whereas otherplatforms simply set up a connection and do not partici-pate in the data exchange. We are more interested in theplatforms that support completely managed experiments.

A platform that supports managed and unmanaged ex-periments is the WebLab-Deusto remote laboratory. Thisremote laboratory is a framework developed to decoupleinfrastructure development and experiment development(Garcıa-Zubia et al., 2009). Through plug-ins and APIsavailable in different client-side and server-side technolo-gies, they achieve certain aims such as scalability or dis-tribution. Regarding infrastructure, the architecture usesa login server for authentication and core server to man-age scheduling, storage, requests, etc. The laboratory andexperiment servers are used to manage the laboratory.The unmanaged experiments can use, for instance, virtualmachines. In the experiments that are managed by theplatform, the communication is made through a set ofcommands using web services. The clients need to use theclient library, with methods for submitting a command,whereas the experiment servers can implement the serverlibrary or use XML-RPC directly.

On the other hand, the University of Technology, Syd-ney (UTS) Remote Laboratory follows an unmanaged ap-proach. The architecture of the UTS remote laboratory isdeveloped to be flexible, extensible and able to managemultiple sets of equipment (Lowe et al., 2009). The userneeds a web browser and a remote desktop client. The userstars session on a web browser, the arbitrator allocatesequipment to the the student, provides visual monitoringof the experiment and boots a virtual machine on a masterserver to enable control of the system. To control the sys-tem, the user creates a remote desktop connection to thisvirtual machine. The arbitrator supports access queuesand management of access to multiple identical systems.

Another example of comprehensive remote laboratory isthe iLab Shared Architecture (ISA) of the MassachusettsInstitute of Technology (MIT), which follows a typicalthree-tier structure. This distributed software toolkit pur-sues scalability, platform independence and efficient man-agement (Hardison et al., 2008). The first tier is the userapplication, available in a web browser. The second tier

is called the service broker, which provides authentica-tion and manages access to the experiments. The thirdtier comprises the lab servers that are connected to thephysical devices and controls the experiment. The labclient and the lab server only communicate directly to theservice broker. For that purpose, two APIs exposed as webservices with pass-through methods are available. Eachexperiment needs a lab server. The clients must be able toproduce and interpret XML documents in compliance witha lab client/server communication schema. The lab serversalso need to interpret and produce those documents andtransform experiment parameters to physical commands.The architecture can be shared between two or more in-stitutions, the two first tiers are located in an institutionand the broker server communicates with the lab serveron charge of the experiment.

As can be seen from the overview of available platforms,there are 3 key issues that need to be addressed in thedesign of a remote laboratory. First, it is necessary todecide how to implement the client-side communication,because this choice influences the development of theclients. Second, we need to establish the functionality andstructure of the core server, sometimes also known asarbitrator or broker. This server, or set of servers, is incharge of authentication, user and session management,resource allocation, etc. and therefore it is crucial in theoperation of the laboratory. Third, the communicationinterface with the control systems of the physical systemsmust be designed. This interface must enable easy config-uration of existing and new equipment in the platform.

The LRA-ULE remote laboratory addresses client-sidecommunication by providing a library for client develop-ment, available both in Java and JavaScript. This libraryprovides a simple interface for system interrogation andI/O operations. The interface communicates with a PHPmodule in the server-side, running in a Drupal contentmanagement system (CMS). The set of CMS, specificLRA-ULE modules developed in PHP and proxy serverperforms equivalent tasks to the broker/arbitrator serversavailable in other platforms (Domınguez et al., 2012). Thisis a similar approach to the one proposed in (Mejıas et al.,2013), where user management is performed by a plug-inof a content management system and another componentcalled Remote Access System for Laboratories (RASLAB)is used to set up the needed links between the user interfaceand the experimental system without compromising secu-rity. Apart from managing the communication between aclient in a public network and the experimental system inthe intranet, RASLAB can also handle the power supplyof that system.

Several approaches have been proposed to alleviate thework necessary to make existing local systems accessiblethrough the web. For instance, a middleware applica-tion (JIL) is proposed in (Vargas et al., 2009) to enablecommunication between clients in the common form ofJava applets and a platform widely used in the field ofinstrumentation, control and acquisition systems such asLabVIEW. This tool have been tested by several Span-ish universities with Easy Java Simulation applets in theclient-side and LabVIEW in the server side.

19th IFAC World CongressCape Town, South Africa. August 24-29, 2014

9716

Regarding the communication with the end systems,the approach taken by the LRA-ULE remote laboratoryshould address its main goal: to connect industrial-orientedequipment. For that reason, it is convenient to reuse com-mon procedures in industry for the communication andcontrol of the physical system. This way, the work andknowledge required to configure or add a system will beminimized. For that reason, contrary to other approaches,the proposed mechanism avoids the implementation of anad-hoc application, using a certain API, in the computerassociated to the physical system. Instead, it uses the OPCData Access standard. OPC provides a common bridgebetween PC applications and process control hardware,with consistent access methods to field data regardless ofthe control system device. Thus, general OPC clients cancommunicate with any hardware as long as an OPC serveris available. Therefore, there is no need to re-implementthe interface for new devices in a SCADA/HMI.

This paper presents a middleware (OPC-DB) that com-municates the industrial systems with a standard databaseassociated to the system. Since the middleware acts as anOPC client, it is only necessary to install and configure theOPC server that is compatible with the control system inthe end computer. The OPC server is usually providedby the manufacturer and its configuration procedure iscommon knowledge among control engineers. Therefore,this approach enables easy and fast configuration of newsystems and, in turn, fewer problems and increased flex-ibility. The main drawbacks are that the acquisition ofOPC servers will increase the cost of the solution and thatsome low-end devices might not be OPC-enabled.

3. THE OPC-DB LINK

In this section, the proposed middleware, OPC-DB link, isdescribed. This middleware connects the physical systemwith the intermediate layer of the remote laboratory byacting as a link between the OPC server associated to thesystem and the database of the remote laboratory.

3.1 Description and purpose of the OPC-DB link

The management system of a remote laboratory generallyrelies on a database that, apart from other information,deals with data sampled from the systems and actionssubmitted by the users. The purpose of the OPC-DB link isto read the status from the input variables of a system andstore them in the database, and to retrieve the actions fromthe database and write them to the corresponding outputvariables of the system. Fig. 1 summarizes this operation.

As discussed in the previous section, communication withthe system is performed through the OPC Data Accessstandard. The middleware works as an OPC client thatobtains from a database the information about whichOPC server and variables it needs to connect to. Thecommunication with the database is performed by meansof a standard ODBC driver. This way, the middlewarepreserves its modularity and independence from the typeof system, so that the integration of new equipment inan existing laboratory is easier. The database needs tobe integrated in the operation of the remote laboratory.It is common that interactions in the client applications

PHYSICAL SYSTEMS

CLIENT SIDE SCRIPT(RICH INTERNET APPLICATION)

Server Side Script

ODBC link

Retrieve/Store

OPC link

OPC-DB Link

Read/Write

DATABASE

REMOTE LABORATORY MANAGEMENT

Fig. 1. General structure of the OPC-DB link

result in the execution of server-side scripts that updateand query the database by means of stored procedures.In that case, the requirements to apply the proposedmiddleware would just be the creation of some tables withthe distinctive parameters of the system (variables, datatypes, OPC tags, etc.). It is also possible to add/erasesystem variables by simply adding/removing rows of thetable. The OPC server of the real system must also beconfigured and activated.

3.2 Functionality of the OPC-DB link

The OPC-DB link carries out several tasks to accomplishits functionality (see Fig. 2). A call to the OPC-DBlink needs two parameters: the name of the databaseassociated with the system and the run or stop command.When a running command is sent, the connection withthe corresponding database is opened and the event andreference to the application instance are registered inthe log table. After that, the configuration parametersassociated to the system (OPC name, sampling period,lifespan limit, etc.), the system variables and their datatype and the OPC tags are retrieved from the database.The data types configured in the database must match theones from the OPC server.

Once all the information is known, the connection to theOPC server is established and the acquisition loop starts.In each iteration of the loop, the values of each of theOPC tags corresponding to the system input variablesare read and stored into a table of the database. Thisway, the remote laboratory services can provide real-timedata of the operation of the system to their clients. Thedata (actions) sent by the remote clients are updated inthe database and, in turn, written to the OPC tags thatcorrespond to the system output variables. However, forefficiency purposes, data are only written when the valuesin the table differ from the ones in the last iteration. In

19th IFAC World CongressCape Town, South Africa. August 24-29, 2014

9717

WEB SERVICE

SYSTEM CONFIGURATION RETRIEVAL

SYSTEM VARIABLES RETRIEVAL

OPC-DB LOG UPDATE

SYSTEMRUN

COMMAND

OPC TAGS RETRIEVAL

OPEN OPC CONNECTION

READ OPC DATA / STORE DATABASE DATA

DATABASE DATA RETRIEVAL / WRITE OPC DATA

ERROR CHECKING

OPC-DB LOG UPDATE

CLOSE DATABASE AND OPC CONNECTIONS

STOP

COMMAND

OPEN DATABASE CONNECTION

DATABASEINDUSTRIAL

SYSTEM

OPC-DB LINK

ODBC

Protocol

VI status (running), time

and reference to VI

clone

OPC

Protocol

Time to live, sampling

period, OPC name, etc

Names and data types

of system variables

OPC tags

Output variables from

the user

Output variables to the

system

Input variables from the

system Store input variables

OPC bad quality, OPC

error, Database error

and time to live limit

Errors, VI status

(stopped) and time

System Database

System OPC server

Fig. 2. Functionality of the OPC-DB link

each loop iteration, possible errors in the connection withthe OPC or the database are checked. The middlewarestops automatically whenever an error is detected andwrites the details in the log. Besides, the quality of thedata provided by the OPC server for each tag is checkedand an error, which stops the middleware, is reportedwhenever the quality of any variable is found to be badfor ten consecutive iterations.

Finally, when the OPC-DB link receives the stop com-mand, it is logged into the database and the connectionswith both the OPC and the database are closed. The OPC-DB link also stops whenever it detects inactivity by theusers, i.e., when a time longer than the lifespan limit haspassed since the last update of the output variables. Theinactivity control avoids the undefined link execution if theremote laboratory platform fails to detect the user exit.

3.3 Programming and deployment of the OPC-DB link

The OPC-DB link has been programmed in LabVIEW 1 ,a graphical programming language developed by NationalInstruments for scientists and engineers, which uses in-tuitive graphical blocks instead of written code for thedevelopment of applications involving acquisition, control,analysis and data visualization (National Instruments,2003). LabVIEW includes extensive libraries of basic and

1 http://www.ni.com/labview/esa/

Fig. 3. Remote client of the electro-pneumatic cell

specific functions for data acquisition, instrumentationcontrol, communication and data storage, as well as aweb server which lets us publish remote front panels, webservices, etc. Standard communication protocols such asserial, GPIB, Modbus, OPC, etc. are also available. Dueto its extensive functionality and connectivity, LabVIEWprogramming language has been chosen.

LabVIEW programs are called Virtual Instruments (VIs)and consist of two parts: the front panel (graphical userinterface) and the block diagram (source code). In thiscase, the design of front panel is not important since theOPC-DB link runs transparent to the user. The LabVIEWproject of the OPC-DB link has been structured in twoVIs: the main VI implements the complete functionality ofthe OPC-DB link whereas the command VI is only usedto command (run/stop) the main one. The LabVIEW VIserver is used to communicate between both VIs. The mainVI is defined as re-entrant to allow that multiple instancesof itself can run in parallel without interfering with eachother. Therefore, the OPC-DB link allows multiple callsso that many users can use different physical systems(different variables, parameters, etc.) at the same timein the remote laboratory. For each different system, adifferent instance is running. On the other hand, thecommand VI is deployed as web service to facilitate theintegration with the management of the remote laboratory.It requires that the LabVIEW web server is active.

4. USAGE OF THE OPC-DB LINK IN THE LRA-ULEREMOTE LABORATORY

As stated before, the LRA-ULE remote laboratory is aplatform used for education and research with a focuson industrial-oriented devices. Therefore, the architecturehas to be flexible enough to be able to integrate newequipment easily. The OPC-DB link is well adapted tothis structure, because it is based on open technologies andfacilitate the communication between the database and aphysical controller regardless of the manufacturer. In thissection, the physical systems that have been connected tothe platform through the OPC-DB link application aredescribed in detail.

The electro-pneumatic classification cell is a physical sys-tem that aims to classify steel pieces (6×6×8 cm) in threecategories This system includes many different industrialequipment such us PLCs, drives, sensors, actuators or a sixdegrees or freedom robot. For the user interaction with theelectro-pneumatic classification cell, an HTML5/AJAX

19th IFAC World CongressCape Town, South Africa. August 24-29, 2014

9718

Table 1. Variables of the system included inthe remote laboratory.

ID System output variables

1 System activation signal2 Activation sequence of the cylinders in the conveyor belt3 Number of cycles performed by the system4 Frequency of the drive5 Acceleration curve of the frequency drive6 Deceleration curve of the frequency drive

ID System input variables

1 Frequency of drive 12 Power of drive 13 Speed of drive 14 Frequency of drive 25 Power of drive 26 Speed of drive 27 System status8 Rail 1 activation9 Rail 2 activation10 Rail 3 activation11 Start signal for code recognition12 Status signal for code recognition

WebAccess

OPC-DB Link

Fig. 4. OPC-DB link application in the LRA platform

client (see Fig. 3) is used. It allows to read and modifysome of the physical system variables, which are shown inTable 1.

Figure 4 shows the architecture to integrate the electro-pneumatic cell into the LRA platform by means of theOPC-DB link. As discussed in section 2, this architectureis three-tier. The first layer is formed by the physicalequipment and their control and acquisition systems. Inthe intermediate layer, there are the servers that managemost of the aspects needed in a remote laboratory. Thecontent management system, web server, security andcommunication manager and database are found in thislayer.

The purpose of this work is to include the OPC-DB linkmiddleware in this intermediate layer to manage the com-munication between the database management system,where the data of the remote laboratory are stored, and thephysical system. The database enables a seamless integra-tion of the OPC-DB link in the platform, which previouslyused other non-standard ad-hoc solutions to provide thatfunctionality. This is achieved by a minor adaptation of thestored procedures to work with the predefined structureof the tables needed to use the middleware. It needs tobe noted that those tables store not only values of thevariables, but also configuration parameters of the linkwith the OPC server.

In more detail, a database suited to work with the OPC-DB middleware must contain the six tables listed in theTable 2. In the “Input variables” and “Output variables”tables, the user must create a row for each of the I/Osystem variables. These tables have three columns: iden-tifier (ID), data type (analog or digital) and OPC tag.Each column of the “OPC data” and “OPC actions” tablescorresponds to a variable of the system. The OPC-DB linkapplication reads the values of the variables introduced inthe “Input variables” table in order to insert them into the“OPC data” table. Apart from that, the middleware de-cides whether to update an output variable in the physicalsystem by reading the current values in the “OPC actions”table and looks up the “Output variables” table to get theOPC tags where the values need to be updated. The “Log-ging” table is used to record the events and errors of themiddleware and the “Config” table includes the addressof the OPC server, the desired sampling period and thedesired maximum idle lifespan. The server-side scripts calldirectly some stored procedures for reading/writing dataand starting/stopping the acquisition. In order to integratethe middleware, those store procedures have been adapted.

On the other hand, it is necessary to configure theOPC server, which in the particular case of the electro-pneumatic cell is a Scheider Electric OPC Factory server.This is achieved by generating a symbol table from thesystem control strategy, in this case implemented in aPremium TSX PLC using Unity Pro. The symbol tableincludes all the variables of the strategy, but only thevariables in the “Input variables” and “Output variables”are used by the remote laboratory.

The top layer includes the client application, implementedwith HTML5 and AJAX, which only communicates withthe server-side script through the library implemented forthat purpose. Therefore, the use of the OPC-DB link willbe transparent to the user.

In addition to the electro-pneumatic cell, the OPC-DBlink application has been used for the communicationwith another physical system, the quadruple-tank model.The steps to include the system are equivalent to thosepresented for the electro-pneumatic cell. A database withthe aforementioned structure needs to be created for thisparticular system. The necessary stored procedures willbe exactly the same than in the previous case, so there isno need to write any further code. The input variables inthis system are basically the levels of the four tanks andthe status of the actuators, whereas the output variablescomprise the speed of the pumps, the openings of the

19th IFAC World CongressCape Town, South Africa. August 24-29, 2014

9719

Table 2. Structure of the database tables

Name Description

OPC actions Output var. sent by Drupal & data typesOPC data Input var. and data types

Config Sampling time, OPC server address & lifespanLogging System errors and events

Input var. Name, ID, type & OPC tag of input var.Output var. Name, ID, type & OPC tag of output var.

valves and the status of the digital valves but also the gainsof the PID controller that is implemented in the strategy.In this case, the OPC Server is an Opto OPCServerbecause the strategy was developed in PAC Control Basicfor an OPTO SNAP Ultimate I/O controller

The OPC-DB link has represented a clear advance regard-ing the workload needed to configure or add a device, whenit uses a control or acquisition system that has an OPCserver available. Several instances of the middleware canrun simultaneously for different systems. The existence ofa single piece of software in the server-side and no ad-hocapplications running in the computers associated with thesystems is also and advantage with regard to maintenanceand reusability.

5. CONCLUSION

The remote laboratories provide web environments to in-teract with physical systems. From a technical point, de-signing a remote laboratory is a complex task. In contrastto the traditional laboratories, where it is just necessaryto select the physical system and develop the educationalcontents, a technological platform to manage student ac-cess has to be developed. This platform is composed ofseveral layers such as the local connection to the physicalsystem, the database and core management system, or theclient interface. A software solution is needed to communi-cate these layers. In the last years, alternatives have beenproposed to implement those communication in standardand reusable applications, but these approaches usuallyfocus on the usage of ad-hoc libraries. To let faculty focuson the development of educational contents, it is necessaryto enable connection of new hardware without much needof programming or technical tasks.

For that reason, we proposed a standard solution to linkindustrial-oriented physical systems with a database inremote laboratories. A middleware has been programmedin LabVIEW, so that the link uses the OPC standardon the side of the physical system and the ODBC driveron the side of the database. If administrators want touse this standard solution to include a system in theirremote laboratory, they only need to install and configurethe OPC server associated to the control system (usuallyprovided by any manufacturer of control equipment) andcreate the associated tables in the database. The proposedlink has been used to integrate two physical systems inthe remote laboratory LRA-ULE at the University ofLeon: an electro-pneumatic cell and a 4-tank process. Thesteps needed to incorporate these systems into the remotelaboratory have been explained in detail. This approachdecreases the workload and knowledge needed to add orconfigure physical systems.

REFERENCES

Domınguez, M., Fuertes, J.J., Prada, M.A., Alonso, S.,and Moran, A. (2011). Remote laboratory of a quadru-ple tank process for learning in control engineeringusing different industrial controllers. Computer Ap-plications in Engineering Education, n/a–n/a. doi:10.1002/cae.20562.

Domınguez, M., Prada, M., Moran, A., Alonso, S., andBarrientos, P. (2012). Improving user interactionin remote laboratories through html5/ajax. In Ad-vances in Control Education, volume 9, 282–287. doi:10.3182/20120619-3-RU-2024.00036.

Eckerson, W.W. (1995). Three tier client/server architec-tures: Achieving scalability, performance, and efficiencyin client/server applications. Open Information Sys-tems, 3(20), 46–50.

Garcıa-Zubia, J., Orduna, P., Lopez-de Ipina, D., andAlves, G.R. (2009). Addressing software impact inthe design of remote laboratories. Industrial Electron-ics, IEEE Transactions on, 56(12), 4757–4767. doi:10.1109/TIE.2009.2026368.

Guzman, J.L., Domınguez, M., Berenguel, M., Fuertes,J.J., Rodrıguez, F., and Reguera, P. (2010). Entornosde experimentacion para la ensenanza de conceptosbasicos de modelado y control. Revista Iberoamericanade Automatica e Informatica Industrial, 7(1), 10–22. doi:10.4995/RIAI.2010.01.01.

Hardison, J., DeLong, K., Bailey, P., and Harward, V.(2008). Deploying interactive remote labs using theilab shared architecture. In Frontiers in EducationConference, 2008. FIE 2008. 38th Annual, S2A–1–S2A–6. doi:10.1109/FIE.2008.4720536.

Leva, A. and Donida, F. (2008). Multifunctional re-mote laboratory for education in automatic con-trol: The CrAutoLab experience. Industrial Electron-ics, IEEE Transactions on, 55(6), 2376–2385. doi:10.1109/TIE.2008.922590.

Lindsay, E. and Good, M. (2005). Effects of labo-ratory access modes upon learning outcomes. Edu-cation, IEEE Transactions on, 48(4), 619–631. doi:10.1109/TE.2005.852591.

Lowe, D., Murray, S., Lindsay, E., and Liu, D. (2009).Evolving remote laboratory architectures to leverageemerging internet technologies. Learning Technolo-gies, IEEE Transactions on, 2(4), 289 –294. doi:10.1109/TLT.2009.33.

Mejıas, A., Marquez, M.J., Andujar, J.M., and Sanchez,M.R. (2013). A complete solution for developing remotelabs. In 10th IFAC Symposium Advances in ControlEducation, 96–101. IFAC. doi:10.3182/20130828-3-UK-2039.00057.

National Instruments (2003). LabVIEW user manual, no.320999E-01. URL http://www.ni.com.

Nickerson, J.V., Corter, J.E., Esche, S.K., and Chassapis,C. (2007). A model for evaluating the effectivenessof remote engineering laboratories and simulations ineducation. Computers and Education, 49(3), 708–725.doi:doi:10.1016/j.compedu.2005.11.019.

Vargas, H., Sanchez-Moreno, J., Dormido, S., Salzmann,C., Gillet, D., and Esquembre, F. (2009). Web-enabledremote scientific environments. Computing in Science& Engineering, 11(3), 36–46.

19th IFAC World CongressCape Town, South Africa. August 24-29, 2014

9720