IEEE TRANSACTIONS ON LEARNING TECHNOLOGIES, VOL. 8, NO.

4, OCTOBER-DECEMBER 2015 393

EJS, JIL Server, and LabVIEW: An Architecture

for Rapid Development of Remote Labs

n, Hector Vargas, Gonzalo Farias, Jose

s Chaco
Jesu
Sa

nchez, and Sebastia

n Dormido

Abstract—Designing and developing web-enabled remote laboratories for pedagogical purposes is not an easy task. Often,
developers (generally, educators who know the subjects they teach but lack of the technical and programming skills required to build
Internet-based educational applications) end up discarding the idea of exploring these new teaching and learning experiences mainly
due to the technical issues that must be mastered. To tackle this problem, authors present a novel technique that allows developers to
create remote labs in a quick, didactical, and straightforward way. This framework is based on the use of two well-known software tools
in the scope of engineering education, Easy Java Simulations and LabVIEW. The development exploits a new feature of Easy Java
Simulations known as EJS-elements that enables Java developers to create and integrate their own authoring libraries (elements) into
EJS, thus increasing its application possibilities. Particularly, the EJS element here presented allows to LabVIEW programs be
controlled from EJS applications through a communication network. This paper presents the element creation details and how this can
be used to create web-enabled experimentation environments for educational purposes. A step by step example of development of a
remote lab for automatic control education is described.

Index Terms—Remote labs, virtual labs, control education, LabVIEW, EJS

1 INTRODUCTION

T HE integration of new pedagogical methodologies to

engineering education is, nowadays, practically manda-
tory in most universities around the world. This statement
experimentation with real processes. For this reason, a full
web-based laboratory should offer both training modali-
ties. However, creating the remote version of a web-based
is grounded by the number of papers published about these lab is still attainable only for educators and research teams
subjects and where the current technological advances have who are expert on these matters, mainly due to the amount
shown the way to follow in this field [1], [2]. For instance, in of technical and programming issues that must be mas-
the European case, this has been addressed by introducing tered [5].
the educative community to the European Space for Higher In the literature, several different approaches oriented
Education (Bologna process), in which Internet plays a key to developing remote laboratories can be found. In [6],
role in university studies [3]. authors present a remote laboratory exclusively created by
Regarding the aforementioned, hands-on laboratory was using the LabVIEW platform [7]. Although LabVIEW VIs1
one of the first places where the integration of such techno- can be easily made ready for Internet delivery, a LabVIEW
logical advances was visible. Many engineering faculties Runtime Engine must be installed on the client side. This
expanded the use of these laboratories by offering students last step is not recommended when creating remote labs
opportunities of experimentation with real systems (pro- since installing software plugins sometimes can become
cesses) not only by live classroom training but also remotely hard for final users. For this reason, LabVIEW platform is
through the Internet. These Internet-based educational tools commonly used only for creating the server side of a
are currently known as web-based laboratories. Web-based remote lab (other software options for the server side can
laboratories are divided into two categories, according to be Matlab [8], Simulink [9], C++ [10], Scicos [11], etc.)
the system’s nature to mvirtual and remote. A virtual labora- On the other hand, Java applets and Flash applications
tory simulates a mathematical model of a physical process, have been the most popular web technologies for develop-
whereas a remote laboratory provides access to a real physical ing the client interface for remote labs. In [12], a virtual labo-
process located in a remote site on the Internet [4]. ratory for the analysis and study of the human respiratory
Although simulation is an appropriate way of comple- system was created. In this example, an applet was devel-
menting engineering education, it generally can’t replace oped by using Easy Java Simulations (EJS) [13], a tool specif-
ically created for designing and developing interactive
virtual labs. Two other interesting examples of remote labs
 J. Chac

on, J. S

anchez, and S. Dormido are with the Department of Inform
a-
tica and Autom
atica, Universidad Nacional de Educaci
on a Distancia, for pedagogical purposes were presented in [14], [15]. In
28040 Madrid, Spain. these articles authors present a set of web-based laboratories
E-mail: jchacon@bec.uned.es, {jsanchez, sdormido}@dia.uned.es. for teaching automatic control concepts where Java applets
 H. Vargas and G. Farias are with the Pontificia Universidad Cat
olica de
to access remotely the training services were used as well.
Valpara
ıso, Chile. E-mail: {hector.vargas, gonzalo.farias}@ucv.cl.
Manuscript received 24 Apr. 2014; revised 8 Oct. 2014; accepted 21 Dec.
2014. Date of publication 8 Jan. 2015; date of current version 11 Dec. 2015. 1. ”LabVIEW programs are called virtual instruments, or VIs,
For information on obtaining reprints of this article, please send e-mail to: because their appearance and operation imitate physical instruments,
reprints@ieee.org, and reference the Digital Object Identifier below. such as oscilloscopes and multimeters”, National Instruments (http://
Digital Object Identifier no. 10.1109/TLT.2015.2389245 www.ni.com/white-paper/7001/en).
1939-1382 ß 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
394 IEEE TRANSACTIONS ON LEARNING TECHNOLOGIES, VOL. 8, NO. 4, OCTOBER-DECEMBER 2015

Similarly, Flash applications have found some applications

in virtual and remote laboratories design [16], [17]. Unlike
Java, Flash has been less used by developers for designing
web-based labs mainly for license payment issues. Another
example can be found in [27], where a remote control labo-
ratory is built using EJS applets and twincat programmable
logic controllers.
Despite all these efforts, simple approaches to assist
beginner’s developers in creating remote labs are not easy
to find. In this context, next lines describe the authors pro-
posal in order to contribute in this scope.
At Spanish National Distance Education University
UNED, distance education courses on automatic control for
as many as 300 students each year are offered. Until few
years ago, these students had to travel from all over the
country to attend two-week long laboratories to complete
the prescribed hands-on experiments in system identifica-
tion and control courses. Fortunately, the development of
Internet technologies highlighted the importance of web-
based teaching and learning in many research fields, includ-
ing automatic control. Since more than 10 years, we there-
fore decided to use web-based labs in our instruction so that
students could minimize their need to physically attend lab-
oratories. The acquired experience for our research team
during all this time can be summarized in the following
selection of papers [18], [19], [20], [21], [22].
Based on the experience above described, we present our
approach to create remote labs. This framework, which is
an update of the work presented in [19], uses the software Fig. 1. Architecture of the remote lab built with EJS, JiL Server and
tools EJS and LabVIEW. The development exploits the new LabVIEW.
feature of Easy Java Simulations known as EJS-elements that
enables Java developers to create and integrate their own illustrate the simplicity of development with this new soft-
authoring libraries (elements) into EJS, thus increasing its ware components.
application possibilities. Particularly, the EJS element here The paper is organized as follows: Section 2 provides a
presented allows to LabVIEW programs be controlled from brief background about the design and development of web
EJS applications through a communication network simply enabled control laboratories. Section 3 describes how the
by linking LabVIEW and EJS variables by means of a config- communication between the client and the server side is
uration wizard. The approach hides the low-level communi- done and how to integrate the EJS Element into a simula-
cation issues always necessary when creating remote labs, tion. Section 4 shows an example of a remote labs used for
thus simplifying its creation process. the teaching of event-based and multivariable control con-
The main contribution of this paper is a methodology to cepts. Finally, some conclusions about the present work and
build new remote laboratories, with a set of software com- future possibilities are given in Section 5.
ponents developed to support the proposed approach.
The main advantage of the proposed approach are the sim-
plicity: a new remote laboratory can be composed rapidly 2 THE REMOTE LAB ARCHITECTURE
by combining several components which have been The basic layout of a remote lab is as follows: on the one
assessed in many applications, and the flexibility: any com- hand, the plant, whose sensors and actuators allow to inter-
ponent may be replaced to adapt to new systems or soft- act with it, is connected to the host PC via an acquisition
ware tools. card (DAQ). On the other hand, the graphical user interface
The developed software components are the EJS Lab- (GUI) that allows students the interaction with the plant,
VIEW Connector Element,2 to simplify the interoperability and which is an application that runs in the student PC.
between EJS and LabVIEW, and a new feature of JiL Server3 This solution is usually known as client/server architecture.
to handle XML-RPC, an standard remote procedure calling An improvement to this approach, adopted in this
protocol (RPC). Because of the layered design, the use of work, is the use of a three-tier architecture (see Fig. 1). In
standard protocols and well-defined interfaces, the architec- this solution, a middle-tier is introduced between the cli-
ture can be adapted to many systems with few extra devel- ent and the server, acting as an intermediary that allows
opment effort. In addition, a remote laboratory with a to eliminate or reduce the dependency of the design and
Quadruple Tank system is provided as an example to implementation of both sides. Thus, the client can focus,
for example, on the interface with the user, and the server
2. https://github.com/UNEDLabs/jil-element on the control of the plant, while the middle-tier copes
3. https://github.com/UNEDLabs/jil-server with the data exchanging issues.

ET AL.: EJS, JIL SERVER, AND LABVIEW: AN ARCHITECTURE FOR RAPID DEVELOPMENT OF REMOTE LABS
CHACON 395

Though there are different alternatives to set up the

server and client PCs, what we are looking for is a solution
that ideally could be applied to any case.
The National Instrument LabVIEW platform has been cho-
sen to setup the server PC. It is a graphical programming
tool, widely spread both in industry and academics, which
allows for the rapid development of applications. One of
the main advantages of LabVIEW is its great hardware sup-
port, providing drivers and libraries to access DAQ systems,
communication protocols, etc.
The middle-tier contains the JiL Server, a LabVIEW appli-
cation developed by authors [21], [24] that provides interop-
erability between LabVIEW and EJS, i.e. the possibility to
remotely control the execution of the laboratory top level
LabVIEW VI and the publication of its controls and indica-
tors to be accessed from the client.
The idea behind this approach is somewhat similar to
the smart device paradigm [29]. This paradigm aims at
enhancing the software while keeping the same hard-
ware. Smarts devices provide an API that exposes serv-
ices to the client, at a minimal state measurement and
state control, should understand various protocols on top
of websockets like JSON or XML, and being capable of
handling user requests. In the same way, JiL Server
extends the capabilities of the server by implementing an
Fig. 2. Class diagram representing the structure of the LabVIEW
API that allows measurement and control of an existing
Connector library for Java and EJS. The the low-level primitives are
LabVIEW VI. The use of XML has been introduced as a encapsulated into the class LabviewConnector. The class LabviewEle-
new feature in the newest version, as well as the handling ment implements the interface to incorporate the library into EJS
of HTTP and XML-RPC requests. simulations.
Finally, the client tier is the most visible part, because it
provides the GUI. The Easy Java Simulations software tool is
a good option because it has been designed to simplify the 3 JAVA AND LABVIEW COMMUNICATION
development of interactive simulations and graphical inter- The JiL Server software encapsulates the connection with
faces. Another advantage of using EJS is its easy integration LabVIEW by handling the client requests through TCP
with Moodle [28], a widespread Learning Management Sys- connections, and providing us with a protocol that
tem (LMS). LMSs have become widespread in distance edu- allows, on the one hand, to control the execution of a Lab-
cation in the last decade, supporting the administration, VIEW VI and, on the other hand, to read the indicators
documentation, tracking, and reporting of training pro- and update the controls of the LabVIEW VI. This means
grams, classroom and online events. that it does not enforce the use of a specific language at
EJS provides us with a mechanism to extend its capa- the client side. Therefore, though this section presents the
bilities, the elements of the model, that encapsulates Java implementation in Java, most of the ideas can be directly
libraries in a way that can be incorporated easily into a translated into other languages.
simulation. The software framework presented hereafter allows the
Here is where the LabVIEW Connector Element fits, hiding communication of a Java applet or application with the
the low-level details of the communication with the Lab- JiL Server with two different levels of abstraction: a low-
VIEW VIs via the JiL Server. The framework is explained in level protocol and a high-level protocol. Therefore, it is
[21], [24] and can be consulted for further details. In the rest divided into:
of this work, we focus on the client side, i.e. on the Java and
EJS implementation.  the LabVIEW Connector, that provides all the low-
Also, a current trend is to propose client in Javascript level functionalities, and
for compatibility with tablets, smartphones and similar  the LabVIEW Connector Element, which provides the
devices. The newest version of EJS has been updated to high level protocol to communicate with the JiL
EjsS, a new feature that introduces the use of Javascript. Server hiding the details to the user. It is a wrapper
Though the discussion in this section considers Java lan- that allows the integration of a library into EJS.
guage, the integration with a Javascript application is The structure of the LabVIEW Connector library is repre-
really simple, since XML-RPC is a well-known protocol sented in Fig. 2. Note that, though the element requires EJS
and there are libraries that can handle with it. Moreover, to run, the Labview Connector core does not have these bind-
a new feature of JiL Server which is being worked on is ings, so it can be used by any Java application. In general,
the implementation of JSON-RPC, which uses Javascript the high-level protocol is the recommended method because
Object Notation (JSON) so it is even easier to process it is easier for the user. However it does not allow a direct
within Javascript. control of the data exchange between the client and the
396 IEEE TRANSACTIONS ON LEARNING TECHNOLOGIES, VOL. 8, NO. 4, OCTOBER-DECEMBER 2015

server. Instead of that, all the variables are synchronized

within each call to the step() method. Therefore, depending
on the number of variables and the communication restric-
tions, the performance might not be optimal. Both protocols
(and components) are explained in the next two sections.
3.1 Low-Level Communication Protocol
The use of the low-level protocol interface is not recom-
mended unless a strict control of the communication is
needed, because it can be error prone. The use of the low-
level protocol is summarized in the following steps:

1) Configure the LabviewConnector class to know the url

of the JiL Server: setServerAddress(url).
2) Connect to the server: connect().
3) Open the remote LabVIEW VI specified by path: Fig. 3. The state diagram represent the possible states of the connection
openVI(path). with the JiL Server.
4) Run the remote LabVIEW VI: runVI().
5) Repeat until stop: First, the url of the JiL Server should be provided either
a) Update the values of the LabVIEW VI controls in the constructor or in the method setServerAddress().
with the get{type}(name) methods. After that, the connection is done with the method connect
b) Read the values of the LabVIEW VI indicators (). The other methods to control the execution are openVI
with the setValue(name, value) methods. (String pathToVI), used to open a LabVIEW VI that must be
6) Stop the remote LabVIEW VI: stopVI(). accessible in the server, runVI() which is used to initiate
7) Close the remote LabVIEW VI: closeVI(). the execution of the previously opened LabVIEW VI,
8) Disconnect from the server: disconnect(). stopVI() to pause the execution of a running LabVIEW VI,
The methods that provide the low-level communication and closeVI() to dismiss an opened LabVIEW VI. Finally,
functionalities are provided by the LabviewConnector class, the method disconnect() closes the connection with the
which is explored in the following paragraphs. server and frees the resources.
The methods that controls the actual data communica-
3.1.1 The LabviewConnector Class tion between Java and the JiL Server are: setValues(String
The LabviewConnector class provides an interface with the name; . . .), which sends a new value to update a control in
methods needed to set up the communication with the JiL the LabVIEW VI, and getDouble(String name); . . . ; getString
Server. The interaction with the server is summarized in the (String name), that obtain the value of an indicator of the Lab-
state diagram of Fig. 3 and the methods to do it are shown VIEW VI. The method setValues(. . .) must be invoked with
in Listing 1. two parameters: a String containing the name of the control
that must be updated, and the value itself. On the other
Listing 1. Class LabviewConnector hand, the methods get{type}(. . .) receive only one parameter,
a String with the name of the LabVIEW VI indicator to be
1: public class LabviewConnector {
read, and return its value. The exact choice of the method
2: public void LabviewConnector(String url)
will depend on the type of the indicator to obtain.
3: public void setServerAddress(String url)
4: public void connect() {...}
3.2 High-Level Communication Protocol
5: public void openVI(String pathToVI)
6: public void runVI() The high-level communication protocol allows the user to
7: public void stopVI() be unaware of the internals of the communication between
8: public void closeVI() the Java application or EJS simulation with the JiL Server
9: public void getMetadata() and LabVIEW VI. This is done by means of the UserLab-
10: public void disconnect() viewConnector class, which is automatically generated with
11: the user-supplied information, i.e. the address of the JiL
12: public void setValue(String name, boolean value Server, the name of the remote LabVIEW VI and the links
13: public void setValue(String name, int value) between the EJS variables and the LabVIEW VI controls
14: public void setValue(String name, float value) and indicators. The configuration is done within the GUI
15: public void setValue(String name, double value) provided by the element (Fig. 8). From a high level point
16: public void setValue(String name, String value) of view, the functionalities that must be provided to the
17: user to allow the interaction with a LabVIEW VI are sum-
18: public void getBoolean(String name) marized in the following points:
19: public void getInt(String name)
20: public void getFloat(String name)  Open and run a remote LabVIEW VI: connect().
21: public void getDouble(String name)  Synchronize the EJS variables with the LabVIEW VI
22: public void getString(String name) controls and indicators: step().
23: }  Stop and/or close the remote LabVIEW VI: disconnect
().

ET AL.: EJS, JIL SERVER, AND LABVIEW: AN ARCHITECTURE FOR RAPID DEVELOPMENT OF REMOTE LABS
CHACON 397

The UserLabviewConnector class contains the high-level  With the configuration provided by the user, it gen-
methods that define a particular connection with a Lab- erates an specialized subclass of LabviewConnector
VIEW VI (Listing 2). Note that these functions are applica- which implement the high level protocol to commu-
tion specific. For example, each LabVIEW VI has its own nicate with the JiL Server and LabVIEW.
controls and indicators. Thus, the synchronization of the values of the linked EJS
variables and LabVIEW controls and indicators is simply
Listing 2. Class UserLabviewConnector done with a call to the method step() inside an Evolution
page, a mechanism of EJS which allows for the introduction
1: public class UserLabviewConnector
extends LabviewConnector {
of Java code to be executed periodically.
2: public void connect(); The configuration of the element require only three steps:
3: public void step(); 1) Add the LabVIEW Element to the current simulation
4: public void getValues(); by dragging and dropping to the Model Elements
5: public void setValues();
page.
6: public void disconnect();
2) Open the LabVIEW Element properties dialog, and
7: }
introduce the url of the server and the path of the
LabVIEW VI to be loaded.
Finally, the LabviewConnectorElement class provides two
3) Link the LabVIEW controls and indicators of the
functionalities: the implementation of the ModelElement
LabVIEW VI with the variables of the EJS simulation.
interface, which defines the contract required by EJS (List-
As mentioned before, it is encouraged to do the commu-
ing 3) to incorporate the library into the software tool as an
nication with the high-level protocol unless there is a good
element, and the code generator to automatize the definition
reason to use the low-level method.
of the UserLabviewConnector class.
Regardless of the chosen approach, in most of the appli-
cations, the variables can be grouped into two classes,
Listing 3. Interface ModelElement namely,
1: public interface ModelElement {
2: public javax.swing.ImageIcon getImageIcon();  synchronous, which are the variables that correspond
3: public String getGenericName(); to controls and indicators that must be updated with
4: public String getConstructorName(); a constant period, because they have a value that
5: public String getInitializationCode(String changes frequently. Examples of this kind of varia-
_name); bles are the control input to the actuators or the
6: public String getDestructionCode(String _name); measures read from the sensors correspond to this
7: public String getImportStatements(); class.
8: public String getResourcesRequired();  asynchronous, which are variables that have the same
9: public String getPackageList(); value the most of the time, only changing sporadi-
10: public String getDisplayInfo(); cally, and they usually correspond to configuration
11: public String savetoXML(); parameters or user commands to interact with the
12: public void readfromXML(String _inputXML); plant.
13: public String getTooltip();
14: public void clear(); 4 EXAMPLE: BUILDING A REMOTE LAB
15: public void setFont(java.awt.Font font); To design a new remote laboratory with the proposed archi-
16: public void showHelp(java.awt.Component
tecture, there are several common activities that must be
parentComponent);
faced:
17: public void showEditor(String _name, java.awt.
Component parentComponent,  Experiments design. Obviously, the starting point is to
ModelElementsCollection list); design the activities or experiments that should be
18: public void refreshEditor(String _name); possible to carry out with the lab. These activities
19: public java.util.List< ModelElementSearch> will usually depend on the hardware availability
search (String info, String searchString, and the teaching purposes.
int mode, String elementName,
 LabVIEW VI implementation. Once the activities have
ModelElementsCollection collection);
been decided and the hardware is ready, the next
20: }
logical step is to implement the LabVIEW applica-
tion that allows to interact locally with the plant. The
functionalities implemented in the server may
3.2.1 The LabviewConnectorElement Class depend on the system, but basic needs are: i) data
The EJS element is implemented by the class LabviewConnec- acquisition to interface with the hardware, ii) safety
torElement. The functionalities provided by this class are measures to protect the plant, and, iii) data logging to
listed in the following points: register experiments data. JiL Server is in charge of
all these functionalities.
 Implement the interface ModelElement, allowing the  EJS user interface. Finally, an user interface must be
class to be recognized as an element and loaded by provided to students in order to carry out the activi-
EJS. ties designed in the first stage.
398 IEEE TRANSACTIONS ON LEARNING TECHNOLOGIES, VOL. 8, NO. 4, OCTOBER-DECEMBER 2015

To illustrate the process, a real example of a remote labora-

tory is presented in this section.

4.1 The Experimental Setup

4.1.1 The Controller
The controller is a PID controller with a level crossing sam-
pling strategy where, depending on the sampler location,
either the sensor sends information to the controller only
when the observed signal crosses certain predefined lev-
els, or the controller sends the new values of the control
action to the actuator when there is a significative change
with respect to the previous value. The level crossing is
considered to be the event that triggers the capture and
the sending of a new sample. Thus, the controller can be
divided into two parts, the continuous transfer function
which corresponds to the non-interacting form of the PID
controller, i.e. CðsÞ ¼ kp þ ksi þ kd s, where ðkp ; ki ; kd Þ are the
controller gains, and the SOD sampler which generates the
discrete events.

4.1.2 The SOD Sampler

The SOD sampler is a block which has a continuous signal
vðtÞ as input and generates a sampled signal vnl ðtÞ as output,
which is a piecewise constant signal with vnl ðtÞ ¼ vðtk Þ,
8t 2 ½tk ; tkþ1 Þ. Each tk is denoted as event time, and it holds
tkþ1 ¼ infft j t > tk ^ jvðtÞ vðtk Þj  dg, except for t0 , which Fig. 4. The three-tier architecture of the Remote Lab. The server is the
is assumed to be the time instant when the block is initial- LabVIEW Virtual Instrument running in the PC connected to the plant,
ized as vnl ðt0 Þ ¼ vðt0 Þ. Depending on the initial value, the the client is the student interface in Easy Java Simulations, and the mid-
dle-tier is the JiL Server, which acts as an interface between the client
non-linearity introduced could have an offset with respect and the server.
to the origin, a ¼ vðt0 Þ id, where i ¼ bvðt0 Þ=dc.

4.1.3 The Plant make it able to handle the streaming, one of them copes with
the image, and is able to reproduce either Motion-JPEG (each
The platform to obtain the experimental data is a remote
frame is codified as a JPEG image) or MPEG-4 (an standard
laboratory compounds of two identical CoupledTank plants
video format) transmitted over HTTP, and the other one
by Quanser [26]. Each plant consists of two tanks and a
plays the audio. The middle-layer is the JiL Server, which
water pump. One of the tanks is placed at the bottom, and
publishes the variables (controls and indicators) of the Lab-
the other at the top. The top tank has a valve whose output
VIEW VI to make them available over a network connection.
goes to the first tank. Thus, the system admits configura-
Further, the third layer is the EJS application in the client
tions of different complexities.
side, which is not only the graphical interface to configure
the control system and/or monitor the plant, but it also con-
4.1.4 The Remote Lab tains the controller implementation itself.
The platform has been developed with the software tools With regard to the communications, from an abstract
Easy Java Simulations [23], [25], JiL Server [24], and Lab- point of view each node is composed of two components: a
VIEW, that are combined to allow the interaction with the signal-generator and an event-generator. For example, for a
plant over the network. The controller is entirely in the cli- sensor node the signal generator can be a zero-order hold
ent side, thus the event-based schemes are adequate that builds the signal from the periodic sensor readings,
because they allow the reduction of the data transmission, and the event-generator is the sampling scheme that decides
thus using more efficiently the network resources. when to communicate the data to another nodes. Note that
The remote lab is based on the three-tier architecture pre- since the event generator can also be configured to emulate
sented in Section 4 (Fig. 4). In the server side, there is a PC a periodic sampling, this approach is also valid to represent
connected to the plant through a Data Acquisition Card a discrete control system.
(DAQ). This PC runs a LabVIEW Virtual Instrument (Lab- From the point of view of the control system, the two
VIEW VI) which implements monitoring functions and acts control loops, depicted in Fig. 5, are considered. In the
as an interface with the plant, i.e. it allows to obtain the read- first configuration, the sampler is placed at the output of
ings from the sensors and sends the control action to the the controller, and in the second one it is situated after
pumps. Also, there is a webcam to transmit a real-time video the process output.
and audio streaming of the plant, to allow students to feel The student interface (Fig. 6) has been implemented in
more like if they were in a real lab, even if they are remotely EJS based on the use of elements, which allows to facilitate
connected. Two view elements (or plugins) provided by EJS the building of the lab and to assure its reliability.

ET AL.: EJS, JIL SERVER, AND LABVIEW: AN ARCHITECTURE FOR RAPID DEVELOPMENT OF REMOTE LABS
CHACON 399

Fig. 5. Two control loops with different location of the send-on-delta sam-
pler. (a) The error signal at the input of the controller is sampled, and (b)
the controller output is sampled.

In addition to the above described LabVIEW Connector

Element, which encapsulates the connection with the JiL
Server, the Process Control Library has been used to imple-
ment the control system. This library provides the user with Fig. 7. At the right of the Model Elements Page, the elements available in
the implementation of the most frequently used systems, the libraries appear as an icon with the name of the element. The list at
such as systems described by state-space expressions, PID the left of the window show the instance of the elements incorporated
controllers, or non-linear systems. Therefore, the user can into the simulation, with their instance names and description strings.
New instances of the elements are created by dragging and dropping
create a model interconnecting different blocks. This the element icons.
approach has several advantages, as it is intuitive and facili-
tates a robust and modular design. With this framework, a These four categories have their associated interface that
wide range of dynamic process control simulations can be defines the methods that a block must implement to be inte-
easily built. grated with the EJS ODE solver and/or the Event Detector.
The library defines four kinds of blocks: The functionality of the Process Control Library is exposed
 Continuous systems, with dynamics described by dif- to EJS through a set of elements (see Fig. 7) associated to the
ferential equations, which are integrated numerically blocks.
by the solver to obtain the evolution. 4.2 Step 1: Adding the Elements
 Discrete systems, which do not have a continuous
Once the control loops have been designed, the first step
flow, but they change their state with a constant sam-
towards the final implementation is to add the Elements to
pling period.
the simulation (Fig. 7). This must be done in order to have
 Event-based systems, which do not have a continuous
them available for the model. Each element can be instanti-
flow, but they change their state only when some
ated one or more times, if it is needed to connect with differ-
condition changes.
ent servers, but usually only one instance is necessary. The
 Hybrid systems, which do have a continuous flow as
name assigned to the element in this step is used to access
continuous systems, but which can also change their
the element in the code.
state and/or their dynamics when some condition
changes. 4.3 Step 2: Setting up the Connection
The LabVIEW Connector Element must be configured prior to
use it in the code. The basic configuration required is the url
where the server can be located, the relative path of the Lab-
VIEW VI and the variables that will be exchanged with the
server. This can be done with the configuration dialog pro-
vided by the element (Fig. 8), which allow to create links
between the EJS model variables and the LabVIEW VI controls
and indicators.
As mentioned before, with the configuration data pro-
vided by the user, the Labview Element generates a class
implementing the high level protocol.

4.4 Step 3: Initialization Code

The method labview.connect() must be invoked to open the
connection with the server. Usually this is done either into
an Initialization, to start the connection automatically, or
triggered by a button of the user interface.
Fig. 6. The interface of the Remote Lab has been implemented in EJS.
The state of the plant is shown by means of the plots at the right, and the 4.5 Step 4: Evolution Code
image obtained from the webcam with augmented reality at the top-left
part of the window. At the bottom-left, the student can configure the con- At this step, the communication with the server is usually
trol system. done periodically, to obtain the new values from the sensors
400 IEEE TRANSACTIONS ON LEARNING TECHNOLOGIES, VOL. 8, NO. 4, OCTOBER-DECEMBER 2015

A significant effort has been dedicated to improve the

ease of use, encapsulating all the low-level issues presented
at the client side into the EJS Model Element mechanism. An
Element is a wrapper that allows us to easily incorporate
Java libraries into EJS simulations, providing with a graphi-
cal user interface to help the developer with the configura-
tion and use of the library.
The LabVIEW Connector Element allows to configure a
connection with a LabVIEW VI, to link EJS variables with
the controls and indicators of the LabVIEW VI, and to con-
trol the execution of the LabVIEW VI. An important feature
of the element is that reduces the possibility of introducing
errors in the code, thus reducing the time and effort needed
for the development phase.

ACKNOWLEDGMENTS
This work has been funded by the National Plan Projects
DPI2011-27818-C02-02 and DPI2012-31303 of the Spanish
Ministry of Science and Innovation and FEDER funds.
The authors would like to thank the Chilean National
Commission for Research, Science and Technology
(CONICYT), for the financial support through Fondecyt
Initiation Project Ref. 11121437. Jes

us Chac

on is the
Fig. 8. The configuration window of the LabVIEW Connector Element corresponding author.
helps the user to configure the connection parameters, i.e. the server
address, the path of the LabVIEW VI file, and the linkages between the REFERENCES
EJS variables and the controls and indicators of the LabVIEW VI.
[1] D. Gillet, A. V. Nguyen, and Y. Rekik, “Collaborative web-based
experimentation in flexible engineering education,” IEEE Trans.
readings, and to send the updates in the control action or Educ., vol. 48, no. 4, pp. 696–704, Nov. 2005.
other parameters. These two things can be done with a call [2] M. Casini, D. Prattichizzo, and A. Vicino, “The automatic control
to the method labview.step() in an Evolution Page. Note that telelab: A user-friendly interface for distance learning,” IEEE
Trans. Educ., vol. 46, no. 2, pp. 252–257, May 2003.
this approach can be rather unefficient as the amount of [3] A. Lareki, J. Mart
ınez, and N. Amenabar, “Towards an efficient
exchanged variables grows. Frequently, the values of the training of university faculty on ICTs,” Comput. Educ., vol. 54,
LabVIEW VI controls corresponds to configuration parame- no. 2, pp. 491–497, 2010.
ters that only changes due to the user interaction. Thus, it [4] N. Duro, R. Dormido, H. Vargas, S. Dormido-Canto, J. S
anchez, G.
Farias, and S. Dormido, “An integrated virtual and remote control
can be a better option to invoke only the method labview.get- lab: The three-tank system as a case study,” Comput. Sci. Eng.,
Values() periodically, and to call asynchronously the method vol. 10, no. 4, pp. 50–59, 2008.
labview.setValues() when needed. [5] L. Gomes and S. Bogosyan, “Current trends in remote labo-
ratories,” IEEE Trans. Ind. Electron., vol. 56, no. 12, pp. 4744–4756,
Dec. 2009.
[6] M. Stefanovic, V. Cvijetkovic, M. Matijevic, and V. Simic, “A Lab-
4.6 Step 5: User Interface VIEW-based remote laboratory experiments for control engineer-
The user interface is shown in Fig. 6. The main window ing education,” Comput. Appl. Eng. Educ., vol. 19, no. 3, pp. 538-
contains two plots which show the process and the control- 549, 2011.
[7] LabVIEW home page. (2013) [Online]. Available: http://www.ni.
ler outputs. Depending on the configuration, the sampler com/labview
output is plotted either with the process output (when sam- [8] G. Farias, R. De Keyser, S. Dormido, and F. Esquembre,
pling the process variable) or with the controller output (if “Developing networked control labs: A Matlab and easy java sim-
the control variable is sampled). From this window it is pos- ulations approach,” IEEE Trans. Ind. Electron., vol. 57, no. 10,
pp. 3266–3275, Oct. 2010.
sible to control the execution of the simulation. In addition, [9] E. Fabregas, G. Farias, S. Dormido-Canto, S. Dormido, and F.
there are three additional windows, one with the configura- Esquembre, “Developing a remote laboratory for engineering
tion of the PID controller, another with the configuration of education,” Comput. Educ., vol. 57, pp. 1686–1697, 2011.
the sampler, and the third one to configure the process. [10] R. Costa, M. Valles, L. M. Jimenez, L. Diaz-Guerra, A. Valera, and
R. Puerto, “Integraci
on de dispositivos f
ısicos de un laboratorio
remoto de control mediante diferentes plataformas: LabVIEW,
Matlab y C/C++,” Revista Iberoamericana de Automtica e Informtica
5 CONCLUSION Ind. RIAI, vol. 7, no. 1, pp. 23–34, 2010.
[11] Z. Magyar and K. Zakova, “SciLab based remote control of
The main contribution of this work is an architecture for experiments,” Adv. Control Educ., vol. 9, no. 1, pp. 206–211, 2012.
rapid development of remote labs. The architecture is based [12] A. M. Hernandez, M. A. Maanas, and R. Costa-Castello, “Learning
on the use of LabVIEW, the JiL Server, and EJS, and allows respiratory system function in BME studies by means of a virtual
laboratory: RespiLab,” IEEE Trans. Educ., vol. 51, no. 1, pp. 24–34,
educators who are not expert programmers to address the Feb. 2008.
development of a remote lab with a minimized learning [13] EJS home page. (2013) [Online]. Available: http://www.um.es/
curve, due to the intuitivity of the graphical tools in the fem/EjsWiki
framework.

ET AL.: EJS, JIL SERVER, AND LABVIEW: AN ARCHITECTURE FOR RAPID DEVELOPMENT OF REMOTE LABS
CHACON 401

[14] J. S

anchez, S. Dormido, R. Pastor, and F. Morilla, “A Java/Matlab- Hector Vargas received the degree in electrical
based environment for remote control system laboratories: Illus- engineering from the De la Frontera University,
trated with an inverted pendulum,” IEEE Trans. Educ., vol. 47, Temuco, Chile, in 2001 and the PhD degree in
no. 3, pp. 321–329, Aug. 2004. computer science from UNED, Madrid, Spain,
[15] J. S

anchez, F. Morilla, S. Dormido, J. Aranda, and P. Ruip
erez, in 2010. Since 2010, he has been with the
”Virtual and remote control labs using java: A qualitative Electrical Engineering School at Pontificia Uni-
approach,” IEEE Control Syst. Mag., vol. 22, no. 2, pp. 8–20, Apr. versidad Catolica de Valparaiso. His current
2002. research interests include simulation and con-
[16] R. Barrett, J. Cona, P. Hyde, B. Ketcham, B. Kinney, and J. Schakel- trol of dynamic systems, multiagent systems,
man. (2003). Virtual Microscope. Univ. Delaware [Online]. Avail- and engineering education.
able: http://www.udel.edu/biology/ketcham/microscope/
[17] J. Goffart, “Design of a web-based remote lab for a brewery proc-
ess,” Master thesis, HAMK Univ. Appl. Sci., H€ameenlinna, Fin-
land, 2007. Gonzalo Farias received the degree in computer
[18] H. Vargas, J. S
anchez, C. A. Jara, F. A. Candelas, F. Torres, and S. science from the De la Frontera University,
Dormido, “A network of automatic control web-based labo- Temuco, Chile, in 2001 and the PhD degree in
ratories,” IEEE Trans. Learn. Technol., vol. 4, no. 3, pp. 197–208, computer science from UNED, Madrid, Spain, in
Jul.–Sep. 2011. 2010. Since 2012, he has been with the Electrical
[19] H. Vargas, J. S
anchez, Ch. Salzmann, F. Esquembre, D. Gillet, and Engineering School at Pontificia Universidad
S. Dormido, “Web-enabled remote scientific environments,” Com- Catolica de Valparaiso. His current research
put. Sci. Eng., vol. 11, no. 3, pp. 34–46, 2009. interests include machine learning, simulation
[20] H. Vargas, Ch. Salzmann, D. Gillet, and S. Dormido, “Remote and control of dynamic system and engineering
experimentation mashup,” presented at the 8th IFAC Symp. Adv. education.
Control Educ., Kumamoto, Japan, 2009.
[21] H. Vargas, J. S
anchez, N. Duro, R. Dormido, S. Dormido-Canto, G.
Farias, S.Dormido, Ch. Salzmann, and D. Gillet, “A systematic
two-layer approach to develop web-based experimentation envi- Jose
Sa
nchez received the computer sciences
ronments for control engineering education,” Intell. Autom. Soft degree in 1994 from Madrid Polytechnic Uni-
Comput., vol. 14, no. 4, pp. 505–524, 2008. versity and the PhD degree in sciences from
[22] R. Dormido, H. Vargas, N. Duro, J. S
anchez, S. Dormido-Canto, G. UNED in 2001 with a thesis on the develop-
Farias, F. Esquembre, and S. Dormido, “Development of a web- ment of virtual and remote labs for teaching
based control laboratory for automation technicians: The three- automatic control across the Internet. Since
tank system,” IEEE Trans. Educ., vol. 51, no. 1, pp. 35–44, Feb. 1993, he has been at UNED Department of
2008. Computer Sciences and Automatic Control as
[23] (2013) [Online]. Available: http://fem.um.es/Ejs an assistant professor. His main research inter-
[24] H. Vargas, “An integral web-based environment for control engi- ests for the time being: event-based control,
neering education,” Ph.D. dissertation, Dptm. Inform
atica y networked control systems, remote and virtual
Autom
atica, UNED. Madrid, Spain, 2010. laboratories in control engineering, and pattern recognition in nuclear
[25] W. Christian and F. Esquembre, “Modeling physics with easy java fusion databases.
simulations,” Phys. Teacher, vol. 45, no. 8, pp. 475–480, 2007.
[26] (2013) [Online]. Available: http://www.quanser.com/english/
n Dormido received the BS degree in
Sebastia
html/home/fs_homepage.html
physics from Complutense University, Madrid,
[27] E. Besada-Portas, J. A. L
opez-Orozco, L. de la Torre, and J. M. de
Spain, in 1968 and the PhD degree in the scien-
la Cruz-Garc
ıa, “Remote control laboratory using EJS applets and
ces from Basque Country University, Bilbao,
twinCAT programmable logic controllers,” IEEE Trans. Educ.,
Spain, in 1971. He received a Doctor Honorary
vol. 56, no. 2, pp. 156–164, May 2013.
degree from the Universidad de Huelva and Uni-
[28] L. de la Torre, “New generation virtual and remote laboratories:
versidad de Almer
ıa. In 1981, he was appointed
Integration into web environments 2.0 with learning management
as a professor of control engineering at UNED,
systems,” Ph.D. dissertation, Dptm. Informatica y Automatica,
Madrid. His scientific activities include computer
UNED. Madrid, Spain, 2013
control of industrial processes, model-based pre-
[29] C. Salzmann and D. Gillet, “Smart device paradigm standardiza-
dictive control, hybrid control, and web-based
tion for online labs,” in Proc. 4th IEEE Global Eng. Educ. Conf.,
labs for distance education. He has authored or coauthored more than
Berlin, Germany, 2013, pp. 1217–1221.
250 technical papers in international journals and conferences and has
supervised more than 35 PhD thesis. From 2001 to 2006, he was the
Jesu
s Chaco
n received the degree in automa-
president of the Spanish Association of Automatic Control, CEA-IFAC.
tion and industrial electronics engineering from He received the National Automatic Control prize from IFAC Spanish
the University of Co
rdoba, Spain, in 2010, and
Automatic Control Committee.
the PhD degree in computer science from UNED,
Madrid, Spain, in 2014. Since 2010, he has been
at UNED Department of Computer Sciences and
Automatic Control as a full time researcher. His
current research interests include simulation and
control of event-based control systems, and
remote and virtual labs in control engineering.