Keywords

1 Introduction

WebLab-DeustoFootnote 1 is an open-source RLMS (Remote Laboratory Management System) developed mainly at the University of Deusto since 2004. As a RLMS, it provides some of the shared features of most remote laboratories, such as authentication, authorization, administration tools, scheduling, analytics, or laboratory sharing. Therefore, if a laboratory is developed on top of WebLab-Deusto (see Sect. 2.2), the laboratory developers do not need to deal with any of those issues: they are provided for them. Furthermore, as new versions of the system are released, the developer can simply upgrade the system without changes in the laboratory and automatically benefit from the new features built into the new versions.

During these years, WebLab-Deusto has been used for the development of remote laboratories in different institutions (see Sect. 2.4), and it is being tested in other universities. The architecture and most of the code have been deeply changed through different iterations during the last years while keeping backward compatibility for existing laboratories. One of the key features of WebLab-Deusto is the sharing model (Sect. 2.3), which has been extended to be integrated in different learning tools (such as LMS or CMS; see Sect. 2.5). The final goal of this sharing architecture is to aim a sustainable model for remote laboratories (see more information in Sect. 2.7).

The remainder of the chapter is structured as follows: Sect. 2.2 explains the technical details of WebLab-Deusto. This section is oriented to a rather technical audience and mainly covers architecture and software topics, while the rest of the sections are intended for technical and nontechnical audience. Section 2.3 explains how any laboratory can be shared among different universities or schools using WebLab-Deusto in a transparent way for the users and administrators. Section 2.4 covers some examples of WebLab-Deusto deployments in different countries. Section 2.5 explains the integration of WebLab-Deusto in different learning tools (including LMS and PLE). Section 2.6 explains research projects where WebLab-Deusto has been used. And finally Sect. 2.7 covers the spin-off of WebLab-Deusto, called LabsLand. Section 2.8 summarizes the chapter.

2 WebLab-Deusto RLMS

When creating a remote laboratory, a remote laboratory developer (a person or group who wants to create a remote laboratory) needs to deal with the management tools (e.g., authentication, authorization, storing logs, viewing logs, administrative tools, etc.) and with the particularities of the remote laboratory (e.g., interfacing with the hardware, developing the user interface, etc.).

WebLab-Deusto is a Remote Laboratory Management System (RLMS). This means that it is a set of software tools and libraries that let remote laboratory developers to focus only on the development of the remote laboratory itself and let the RLMS manage the rest (by managing authentication, groups, authorization, scheduling, integration in learning tools, analytics, or sharing).

To this end, WebLab-Deusto provides an architecture (see Fig. 2.1), where the clients interact with WebLab-Deusto for requesting access to a laboratory, and the laboratory is only contacted when the current user has permission to use the laboratory at a particular time slot (managed internally by a queue of users). Depending on the approach selected by the remote laboratory developer (managed or unmanaged, explained in more detail in Sect. 2.2.3), the communications with the laboratory will be performed through the WebLab-Deusto main server (which will store and forward the user requests) or directly with the final laboratory.

Fig. 2.1
figure 1

WebLab-Deusto local architecture

Full size image

This way, remote laboratory developers can develop their laboratories in any programming language or web framework, and by using certain interfaces, WebLab-Deusto automates the rest of the processes. For example, if someone wants to develop a laboratory using a Raspberry Pi (an inexpensive – $35 – single-board computer) controlling a set of electronic devices, the remote lab developer can develop the software as they prefer (in Python, PHP, or other software frameworks) running in the Raspberry Pi and a web interface for the users. Then, by providing some HTTP interfaces and sharing a couple of secret messages with a WebLab-Deusto server (deployed in the same Raspberry Pi or in a regular computer), the remote lab developer does not need to implement a connection to a Moodle (because WebLab-Deusto provides that connection; see Sect. 2.5), does not need to implement a queue of users (because WebLab-Deusto already provides it), does not need to deal with sharing the lab securely with other institutions (because WebLab-Deusto already does it), or does not need to deal with writing analytics software on when the lab was used (because WebLab-Deusto already does it).

The two approaches provided by WebLab-Deusto are programming language agnostic, so developers can use any programming language to implement them (and even libraries in different programming languages – Python, Node.js, Java, .NET, C++, or C, among others – are provided by WebLab-Deusto); and the interfaces are defined to be as simple as possible, making most of the methods optional.

This section of the chapter covers the technical aspects mentioned in more detail: Sect. 2.2.1 briefly explains the software, while Sect. 2.2.2 explains the features provided by WebLab-Deusto, Sect. 2.2.3 explains the architecture and development approaches, and Sect. 2.2.4 compares it with other RLMSs.

2.1 WebLab-Deusto Software

WebLab-Deusto is an open-source (BSD 2-clause license) project. The source code is available in GitHub,Footnote 2 always including the latest changes in the main branch. The complete documentation is available in Read the Docs.Footnote 3 It includes the installation process, a step-by-step guide on how to deploy WebLab-Deusto, and the details on the different development strategies.

The WebLab-Deusto software relies also on open-source technologies (Python, several Python open-source libraries including Flask-SQLAlchemy, Git, etc.), and its server software can be installed on Linux, Mac OS X, or Microsoft Windows. The client is a regular web application, so WebLab-Deusto itself does not impose any special requirement to the client other than a modern web browser (working on mobile devices, tablets, and regular desktops). However, each laboratory can use different technologies, so if the laboratory uses a technology that does not work in certain devices (e.g., Adobe Flash, which does not work in mobile devices or tablets), those limitations will be applied. All the laboratories developed by the WebLab-Deusto team only require a web browser (Garcia-Zubia et al. 2008), and the team has contributed to other remote laboratories for HTML5 adoption (as in the case of VISIRFootnote 4).

2.2 WebLab-Deusto Advanced Features

This section describes briefly each of the main features of WebLab-Deusto. It just aims to give a more narrow idea on what each of the features mean, but more documentation is available in the WebLab-Deusto documentation site. An important feature (sharing laboratories) is missing in this section since it has a dedicated section for it (Sect. 2.3).

2.2.1 Security

WebLab-Deusto has been designed to be secure. At user level, as stated in Sect. 2.2.2.7, it supports different authentication mechanisms, most of which enable that the passwords are not stored in the WebLab-Deusto server, and in some, the password does not even go ever through the WebLab-Deusto servers.

Additionally, all the communications between client and server (and between servers when sharing laboratories) are managed through HTTP, and therefore they can be secured using HTTPS. The only exception is the unmanaged laboratories (Sect. 2.2.3.2), where the communications are managed by the remote laboratory developer, but in the case of the University of Deusto, all the unmanaged laboratories use HTTPS. This also solves any problems with firewalls and proxies (Garcia-Zubia et al. 2009), and given that all the software provided by WebLab-Deusto relies on HTML5, it can run on any web browser (even in mobile phones).

At laboratory level, the WebLab-Deusto architecture offers the managed approach (Sect. 2.2.3.1), where the software developed by the remote lab developer is isolated in a local network at the university level. This avoids common issues generated by remote lab developers who are experts on the hardware side but may not know several pitfalls when dealing with security. Given that all the communications are forced to work through an API on the client side and on the server side, and WebLab-Deusto stores and proxies all those communications, the vulnerability window is considerably smaller than in other architectures.

2.2.2 Interoperability

WebLab-Deusto supports interoperability with external tools at two levels:

  • Other Remote Laboratory Management Systems (supporting bidirectional integration with iLab laboratories and Universidad Nacional de Rosario laboratories through the federation mechanisms Orduña et al. 2013)

  • Learning tools (including a wide range of learning management systems) as explained in more detail in Sect. 2.5.

Furthermore, WebLab-Deusto relies on different open-source technologies and supports deploying the server in Linux, Microsoft Windows, and Mac OS X.

2.2.3 Learning Analytics

When a student uses a laboratory, WebLab-Deusto stores who accessed and when and, in the case of the managed laboratories, also all the commands and files that were sent during the session.

This enables WebLab-Deusto to report this information to both the administrators and the instructors of the groups. In particular, instructors can see (Fig. 2.2) both the global trend of the class and also the usage done by particular students.

Fig. 2.2
figure 2

Parts of the learning analytics panel of WebLab-Deusto for a group of students

Full size image

Furthermore, as detailed in Orduña et al. (2014), if a particular laboratory requests files to be submitted (e.g., typically code or binary files to be programmed in a device), WebLab-Deusto automatically compares which previous uses of the lab in class were done with the same files and had not been previously used by an instructor or administrator. This way, it can discover potential plagiarism among students, reporting the non-explicit social network in class.

2.2.4 Scalability and Scheduling

WebLab-Deusto has been designed to be scalable at different levels: user, laboratory, and sharing.

At user level, it supports different deployment options so as to be able to scale horizontally (adding more servers) and vertically (using more powerful servers) to deal with higher levels of usage of concurrent students. It supports both lightweight deployments (using SQLite Sect. 2.2.2.6) and scalable deployments (using Redis and MySQL). Furthermore, it comes with tools for measuring a particular deployment, by simulating students using different strategies, so it is possible to establish what policies are better for a particular server. In Orduña (2013) it is analyzed how the software behaves with different loads of simulated users (up to 150).

At laboratory level, WebLab-Deusto supports load balancing. WebLab-Deusto supports an internal queue of users that aim to access a particular experiment. This way, WebLab-Deusto guarantees that only one user can access a laboratory at a time, and the rest of the users are waiting in that queue. The architecture has also been designed to manage multiple experiment servers (the experiment-dependent software) through a different laboratory server (a software component of WebLab-Deusto that performs regular checks on the labs and manages part of the communications with the laboratories), so it is possible to increase the number of laboratory servers without adding more processing load to the main servers.

However, when a laboratory is going to be accessed by several students, a common solution is to provide multiple copies of the same laboratory. For example, in the University of Deusto, in electronics laboratories more than one copy has been provided (see Fig. 2.3). WebLab-Deusto can be configured, so the students will be randomly going to one or other copy of the laboratory, and the rest will still wait in a shared queue. The local scheduling mechanisms are detailed in Orduña and García-Zubia (2011).

Fig. 2.3
figure 3

Example of local load balance of users among copies of the same laboratory in the University of Deusto

Full size image

Finally, at sharing level WebLab-Deusto supports federated load balance: if two institutions have a copy of a laboratory, they can balance automatically the load of users of both institutions among the different copies in each system, without the need to register students from one side to the other. This is covered in Sect. 2.3 of this chapter.

2.2.5 Hybrid Laboratories

Remote labs let users access real, physical equipment through the Internet, while virtual labs let users access simulations (Ma and Nickerson 2006). Traditionally, remote labs have been designed to mimic a hands-on experience. However, there are ongoing research efforts to design new models of laboratories which provide additional features and advantages. One of such models is hybrid labs (Rodriguez-Gil et al. 2016).

A hybrid lab mixes virtual and real components to leverage some of the advantages of both. Though those depend on the specific lab, examples of such advantages could be cost-effectiveness, higher realism than purely-virtual labs, and features such as gamification or virtual environments.

The extensible and fully web-based architecture of WebLab-Deusto allows and facilitates the development of such labs. An example is the hybrid FPGA laboratory described in Rodriguez-Gil et al. (2016) and depicted in Fig. 2.4. Through it, students can program a real, physical FPGA which is used to control a virtual model of an industrial water tank. The virtual model has both sensors (water level and temperature) and actuators (two water pumps), which interact bidirectionally with the real, physical board. Thus, students program in a realistic environment (the board they program is real) but with a lower cost than purchasing and maintaining a real industrial water tank model would entail.

Fig. 2.4
figure 4

FPGA-water tank hybrid lab architecture

Full size image

2.2.6 Embedded Deployments

WebLab-Deusto is a very light system, which does not require much memory or processing power. Indeed, we have successfully deployed the whole system even in Raspberry Pi 1 devices and measured the results (Angulo et al. 2013). On this ARM device, with only 256 MB RAM, could manage different amounts of concurrent users. So as to measure this, WebLab-Deusto comes with tools for simulating concurrent students in different environments.

However, the amount of time increased fastly per student, so it is not recommended to deploy the whole system in such an inexpensive device (around $35). The typical deployment would include the general layers of WebLab-Deusto in a regular server (which can be a normal computer, depending on the expected load of concurrent users), and the experiments then can be deployed in constrained devices such as Raspberry Pi.

2.2.7 Authentication and Authorization

WebLab-Deusto supports different authentication mechanisms. The simplest (and default) one is storing in the database the username and a salted hash of the password (the standard secure procedure when working with passwords: instead of storing the password, it stores a hash of the password, so if someone gets access to the database, the person can’t figure out what was the original password).

However, in many contexts this is inconvenient, since this leads to creating yet another account for students and maintain and remember the passwords. So as to provide a more integrated solution, WebLab-Deusto also supports LDAP, which is a protocol used internally in many universities for user management. This way, the users can have the same credentials as in the university, and no password will be stored in the WebLab-Deusto server.

In addition to these two approaches, WebLab-Deusto provides support for other protocols such as OpenID and OAuth 2.0 (used with Facebook) as well as an API for developing third-party protocols. For example, certain universities count with other types of authentication (e.g., based on encrypted cookies), so with this API, it becomes possible to add support for those mechanisms.

Regarding authorization, WebLab-Deusto provides tools for adding users to groups and granting access to certain laboratories to each group or individual. However, it also supports delegating it to remote other tools such as LMS as explained in Sect. 2.5.

2.3 Managed and Unmanaged Labs

A remote laboratory consists of two parts: a client and a server. Depending on the technology used, both can be very isolated or not. For example, in many web frameworks, there is no such distinction, while in many occasions, the remote lab developer might want to have a clearly separated set of technologies (such as a JavaScript client that only performs some interactions with the server).

As shown in Fig. 2.1, a WebLab-Deusto server can be managing both managed and unmanaged laboratories. The distinction between the two approaches is the following:

  • A managed laboratory (Sect. 2.2.3.1) is a laboratory where the communications between the client and the server side are managed by WebLab-Deusto. Therefore, the remote lab developer must implement a client (using a JavaScript library provided by WebLab-Deusto) and a server (using any programming language, either using the libraries provided – for Node.js, Python, Java, .NET, C++, or C – or implementing the required protocol by WebLab-Deusto). WebLab-Deusto will be in charge of showing the client when it is necessary and to communicate both (i.e., when the client calls a function sendCommand(message), the server will receive that message).

  • An unmanaged laboratory (Sect. 2.2.3.2) is a laboratory where WebLab-Deusto is totally unaware of the communications between the client and the server. Typically this means that the remote laboratory developer provides a complete web application (managing all the communications) and implements a RESTful interface that WebLab-Deusto calls. This way, WebLab-Deusto will call certain methods to state “a new user, called Michael and identified by this token, comes now” or “the current user left or has timed out,” and the web application will be responsible of making this happen.

There are advantages and disadvantages in both approaches, explained in each section, and that is the reason for both approaches coexisting and being supported.

2.3.1 Managed Labs

As represented in Fig. 2.1, in the managed approach, all the users interact only with the WebLab-Deusto “core” servers and never with the particular experiment servers. A single “core” server can be in charge of dozens of managed and unmanaged laboratories at the same time. In the case of the “managed” laboratories, all the commands will be sent through these servers, which will forward the commands to each laboratory. The system has been designed to minimize the latency added to each command submitted (Orduña 2013).

The managed approach is simpler for certain developers that might not be familiar with web technologies. Writing an HTML + JavaScript code that calls simple functions for submitting commands and not dealing with tokens, authentication, or communications can be easier.

Additionally, all the communications are managed by the WebLab-Deusto servers, which also add some simplicity:

  • If the administrator adds support for HTTPS to provide encryption, all the managed laboratories automatically support it too.

  • Only a web server (WebLab-Deusto) requires to be deployed. Once running, all the managed laboratories can be in a private network without dealing with ports, firewalls, configuring web servers, etc.

  • Since the access from the Internet is totally restricted, each managed laboratory will never have more load of users than the one defined by the configuration of WebLab-Deusto (e.g., only one user at a time or some users if it requires some collaboration). This makes the approach ideal for constrained devices, since no security needs to be managed at experiment server level.

  • Everything is automatically stored in the database, and it is available to instructors and administrators.

2.3.2 Unmanaged Labs

As represented in Fig. 2.1, in the unmanaged approach, all the users interact with the WebLab-Deusto “core” servers but also with the experiment servers, using whatever protocol is desired by the remote lab developer. WebLab-Deusto is unaware of these communications, so no constraint is established.

The unmanaged approach is better for web developers who use web frameworks and do not want to limit to a simple client and server. The fact of not managing communications enables developers to use any type of protocol (such as WebSockets) without constraining to the libraries of WebLab-Deusto. Additionally, the approach is more scalable since, if there are more laboratories, the requests for one laboratory and for the other are not managed by the same core servers.

However, the flow is also more complicated, since it requires implementing a set of features such as:

  • Receiving a message of a user coming (with some metadata of the user and a token for identifying).

  • Rejecting users who do not have a valid token.

  • Receiving a message that the user session is expired and therefore the user must be rejected in the next request.

  • Tracking if the user is active or not and notifying WebLab-Deusto when requested (so if the user left, WebLab-Deusto can assign the laboratory to the next student in the queue).

In this case, examples for Python and PHP are provided in the documentation site, as well as definitions of the particular methods and parameters.

2.4 Comparison with the State of the Art

The concept of RLMS, through different names, is commonly used for almost a decade. The main RLMSs available are MIT iLabsFootnote 5 (Harward et al. 2008a,b), RemLabNetFootnote 6 (Schauer et al. 2016), and Labshare SaharaFootnote 7 (Lowe et al. 2012a,b). Other systems (such as LiLa Richter et al. 2011) are not really comparable as they are an index of existing publicly available resources.

Both MIT iLabs and Labshare Sahara and WebLab-Deusto are open source and publicly available, while RemLabNet is still not available for usage by third parties. MIT iLabs and WebLab-Deusto are the only ones supporting federation, while MIT iLabs does not support federated load balance or transitive federation. WebLab-Deusto and Labshare Sahara are the only ones supporting local load balance when it comes to scheduling. MIT iLabs and Labshare Sahara are the only ones supporting calendar-based booking (and in particular Labshare Sahara supports a very interesting and complex mechanism for supporting queueing and scheduling at the same time Lowe and Orou 2012). The approach taken by MIT iLabs to support LMS is a joint effort with WebLab-Deusto (as described in Sect. 2.5), and it has also been extended to RemLabNet for its support in the Go-Lab project (Sect. 2.6).

3 Sharing Laboratories

WebLab-Deusto supports federating laboratories (Orduña et al. 2013): this means that one WebLab-Deusto deployment can share its laboratories with other instances, as well as consume them.

The way it works is the following (Fig. 2.5): a University A has an Experiment 1, and University B has Experiment 2 and Experiment 3. University A can create a particular type of user (federated user), which represents another institution (University B in this case). Then, it can share with that particular user a set of laboratories (in this case, Experiment 1). From this moment, University B has access to Experiment 1, so it can be treated just as any other local experiment. University B might let only one group of University B students access this laboratory. In any case, University A is unaware of who has permission at University B: the relations are in a university-to-university basis, never in a university-to-other-students basis. This simplifies the mechanism, since each university manages its own students, groups, and permissions, and in addition to that, they just have access to some more laboratories from other universities.

Fig. 2.5
figure 5

WebLab-Deusto federation

Full size image

The way this sharing is performed can also be configured in different ways. For example, University A might decide that their own students will advance faster in the queue, so they will use the laboratories faster. This way, if one student is using the Experiment 1, and a student of University B comes into the queue and then a student from University A comes in, this student will go first in the queue. WebLab-Deusto enables this type of policies, but it is up to the particular universities to define them. Also, in the case of University B sharing laboratories with University A, University B can select whether to share all the laboratories or only few of them to University A.

Two key features of the federation model of WebLab-Deusto (Orduña 2013) are that it supports:

  1. 1.

    Transitive federation: if University A shares a laboratory with University B, then University B can re-share that laboratory with University C. At every moment, when a student comes, University A will be aware of the student coming from University C. This enables complex chains (Orduña et al. 2013) of sharing laboratories where University C could be a secondary school of the area of University B which would otherwise less likely be aware of the laboratory.

  2. 2.

    Federated load balance: if University A and University B have the same laboratory (which happens, e.g., in the VISIR laboratory Gustavsson et al. 2007, available in several countries), then they can balance the load of users between both copies of the laboratory. This way, students of University A requesting the laboratory would always be redirected to the local laboratory. But, if there is a queue, a meta-queue is formed in both institutions, and whichever laboratory is available earlier will be used. On top of this queue, the same rules explained above (e.g., priority of local students) are maintained.

The combination of both features is also possible, so if University A and University B had the same laboratory, any of them could still share it with University C.

4 Examples of WebLab-Deusto Deployments

This section covers a set of examples of remote laboratories developed using the WebLab-Deusto RLMS. Each section has been written by the authors of each of the laboratories in each institution.

4.1 University of Deusto

The remote laboratories research group of the University of Deusto has extensively used WebLab-Deusto for developing its own remote laboratories, with over 100,000 uses. This includes programmable laboratories (CPLDs, FPGAs, Microchip PICs, ARM devices) – where students write some code and send it to the device – as well as robots, electronics, and biology laboratories. A demo of the currently active laboratories is available.Footnote 8 In Fig. 2.6, the Archimedes laboratory is presented, where secondary school students can drop balls with different mass to tubes and measure the results (Garcia-Zubia et al. 2015).

Fig. 2.6
figure 6

Archimedes remote laboratory (Garcia-Zubia et al. 2015)

Full size image

4.2 STUBA: Process Control Remote Laboratories

Institute of Information Engineering, Automation and Mathematics (IAM) at STU in Bratislava is one of the main Slovakian educational institutions in the field of automation and process control. IAM has been active in the development of remote laboratories for almost a decade. Most of the developed labs are designed for the applications of control theory and practice. This also influences the nature of the experiments provided as remote labs. Unlike the labs from the fields of electronics and robotics, the IAM labs mostly use the training models of technological processes and systems, which exhibit an internal dynamics in a continuous manner. These are, e.g., processes with transfer and accumulation of heat or mass. This fact brings new requirement on server-side hardware since it must be able to sense the analog signals and control the actuators also in the analog fashion.

In the past, each remote laboratory at IAM was designed as the ad hoc solution, managing its own resources, as well as the user access mechanism. In 2013 the institute has adopted the Remote Laboratory Management System (RLMS) WebLab-DeustoFootnote 9 (Kalúz et al. 2013). Approximately in that time, a new type of architecture for development of remote laboratories has been developed (Kalúz et al. 2015) and used for implementation of several experiments for automatic control. Developed laboratories contain the following experiments:

  • DC-motor (Fig. 2.7) – this experiment exhibits the dynamical behavior of first-order mechanical system;

    Fig. 2.7
    figure 7

    DC-motor remote laboratory

    Full size image

  • Thermo-optical device (Fig. 2.8) – provides a multi-input-multi-output system with coupled states. This system contains thermal and optical channel to control;

    Fig. 2.8
    figure 8

    Thermo-optical device remote laboratory

    Full size image

  • Air heat exchanger – designed as air turbine with heating element is the system with two inputs and two outputs;

  • System of cascaded liquid storage tanks – is a very popular educational device, which represents the dynamical system of second order.

The graphical user interface (GUI) of laboratories is fully customizable, and it is designed as a workspace with draggable windows. It contains several types of predefined components, which are main control panel located at top of Web page; tables with inputs, outputs, and variables located at fixed position in left-hand side of interface; a set of charts with visualization of signals and variables; window with selection of control algorithms; a set of video streams from remote video devices; window for download of measure data; and event-logging window.

These laboratories have been used in the education process for more than 3 years as the supplementary tools for practical exercises. They have been directly incorporated into curricula of two courses, namely, in the Integrated Control in Process Industries and Theory of Automatic Control. Students have to handle several tasks during their practical work. These are the measurement of step responses of laboratory system in order to obtain the mathematical model, experimental identification of model’s parameters, a design of appropriate controller (usually the PID), and evaluation of control quality.

During the period when the laboratories were used in teaching, there have been 2179 laboratory sessions by students. The DC-motor laboratory has been used 897 times and thermo-optical device laboratory 927 times. Other laboratories are not the direct part of curricula, but they have been still used 373 times, mostly during the students’ projects.

4.3 Control Systems Remote Laboratories in Flipped Classroom Context

In 2012, the Ecole des Mines school of engineering (Nantes, France) and the University of Los Andes’ school of engineering (Bogotá, Colombia) started a collaboration around the implementation of control system remote laboratories within the WebLab-Deusto initiative. The web interface (Fig. 2.9), LMS integration and back-end interfaces developments were conducted in collaboration between the three entities during more than 3 years in order to reach an effective managing interface from heterogeneous technologies infrastructures (Barrios et al. 2013b). While in the French context, the laboratory was proposed to students on a traditional course modality during 3 years, in the Colombian university, a flipped classroom (or inverted classroom) modality was used after 2 years of traditional course. Three control system plants were developed for the Colombian context: two axle position control systems (Barrios et al. 2013a,b) and a “ping-pong ball” control system (Caro and Quijano 2011). The last investigations we have conducted on this kind of laboratories were about the comparison between two modalities, real lab vs remote lab (Barrios et al. 2013a), and the interpretation of our results which contrast to some of international research results (Canu and Duque 2015).

Fig. 2.9
figure 9

Remote laboratory user interface

Full size image

4.4 UNED: VISIR in SPOC and MOOC

DIEEC-UNED (Electrical and Computer Engineering Department, National University for Distance Education) has been working actively with a modified version of VISIR (see Fig. 2.10) and WebLab-DeustoFootnote 10 since February 2016. WebLab-Deusto allows management VISIR operation in expertise courses and SPOCs (Small Private Online Courses).

Fig. 2.10
figure 10

VISIR system adapted by UNED-DIEEC, used through WebLab-Deusto

Full size image

During the 1st semester of the academic year 2016–2017, over 150 students from an engineering degree subject (“Fundamentals of Electronics Engineering”) will access VISIR remote electronic lab through WebLab-Deusto. Furthermore, VISIR and WebLab-Deusto will be part of a redesigned massive open online course (MOOC) titled “Circuits Fundamentals and Applied Electronics” (Macho et al. 2016; García et al. 2014), 2017. This MOOC course had just had over 7,000 enrolments in the last 3 years.

In the course of these months of activity with VISIR and WebLab-Deusto, over 750 accesses were performed. These students have accessed VISIR lab as federated users from LMS (Learning Management System) platforms (Ruiz et al. 2014) by means of the WebLab-Deusto federation API through a custom system developed at UNED that uses the internal authentication mechanism. The rest of accesses are the stem from sessions aimed at experiments design by teachers/instructors and administrative tasks.

Besides the authentication mechanisms, a key factor for integrating WebLab-Deusto at DIEEC-UNED is that WebLab-Deusto includes the necessary support for monitoring the requests/responses between remote lab VISIR and final user. Before WebLab-Deusto, users’ activity in VISIR was almost invisible for administrators. WebLab-Deusto allows monitoring all the users’ interactions within the lab. This feature makes feasible the development of educational self-assessment tools and grading tools for VISIR.

4.5 Other Examples

In addition to the examples presented in this section, WebLab-Deusto has been used in other institutions, such as in the Pontifical Catholic University of Sao Paulo in Brazil andFootnote 11 University of Niš (Milošević et al. 2016), among others.

5 Integration in Learning Tools: gateway4labs

The strengths of a RLMS are the management and development of remote laboratories and making it easy to integrate them in external systems. This last point is particularly important since RLMSs must support its integration in systems where instructors or teachers put the learning resources, including Learning Management Systems (LMSs) and Personal Learning Environments (PLEs).

In this line, in 2012, the WebLab-Deusto team started a project originally called lms4labs (then gateway4labs/Go-Lab Smart Gateway Orduña et al. 2015) which aimed to be an open-source tool that would help the remote laboratories community to address this issue, by providing a simple protocol to connect virtual and remote laboratories to different types of learning tools (including PLEs and LMSs). As depicted in Fig. 2.11, gateway4labs is a middleware that supports three protocols:

  • IMS LTI (Learning Tools Interoperability): a standard that supports interoperability between different learning tools in a secure way. In the context of gateway4labs, it is possible to create credentials for each teacher or groups of teachers, and they can use them in their courses in their LMS for accessing each particular laboratory.

    Fig. 2.11
    figure 11

    gateway4labs/Go-Lab Smart Gateway

    Full size image

  • OpenSocial: a standard used in Graasp,Footnote 12 partially developed as part of the Go-Lab projectFootnote 13 (de Jong et al. 2013, 2014; Gillet et al. 2013).

  • HTTP: a custom simple protocol using HTTP and JSON, used for those circumstances where there is no support for IMS LTI or OpenSocial

Thanks to this component, any of the laboratory systems on the right side (including WebLab-Deusto and therefore any remote laboratory developed using WebLab-Deusto) can be consumed by any of the tools on the left side. In the case of IMS LTI tools (which include Moodle, Sakai, Blackboard, or Open edX), the integration is secure, so the laboratories do not need to be publicly available if the remote laboratory developer does not need to. In the case of OpenSocial, the remote laboratory developer must enable that the particular laboratory becomes an open educational resource, and therefore anyone will be able to use it without any authentication.

The advantage of using gateway4labs for laboratories is that, if the instructor is using a LMS (such as Moodle or Sakai), then there is no need to register the students and groups in WebLab-Deusto. This way, the analytics tools of WebLab-Deusto are not available, and the authentication and authorization features of WebLab-Deusto are not used (which is not a problem since LMS provide these features). And the management of the laboratories (queueing, federating, administration tools) is still made by the WebLab-Deusto instance.

6 WebLab-Deusto in Research Projects

WebLab-Deusto research team has designed and deployed the WebLab-Deusto platform and some remote experiments during the last more than 10 years. The first design of WebLab-Deusto was an intrusive program written in C to control and program remotely a programmable device. It was tested during the CLEI Conference in 2003 in La Paz (Bolivia). This section is devoted to describe the projects in which the WebLab-Deusto is involved and the tasks assigned to it. This set of projects and tasks describes the potentiality of the WebLab-Deusto platform in the present and in the future.

Under the name of WebLab-Deusto, different products and research have been obtained and applied in different national and international granted projects. There are two different products in WebLab-Deusto: the remote experiments and the Remote Laboratory Management System, WebLab-Deusto RLMS. The second product is the most important, but during the last 10 years, more than 20 remote experiments have been designed in and for supported projects: FPGA, CPLD, PIC, ARM, Archimedes principle, robotics, aquarium sensoring, etc. In 2005 the Rex-Net (Alves et al. 2005) was the first European project that included WebLab-Deusto experiments.

The WebLab-Deusto RLMS also allows users and partners to connect, to offer, to control, and to track remote experiments, designed or not by the partner or by other designers. This is the main result of the WebLab-Deusto research team.

In some projects, all the design experiments were offered through the WebLab-Deusto RLMS, being this platform the portal of the project. In OLAREX,Footnote 14 WebLab-Deusto was used by the National Polytechnic Museum of Bulgaria, by the Urdaneta School in Bilbao, and by other partners, schools, and institutions to offer remote experiments. In iCo-op projectFootnote 15 WebLab-Deusto deployed a set of experiments in Georgia under the WebLab-Deusto RLMS, and the same situation occurred in Serbia with the NeReLa project.Footnote 16 In VISIR+ (Alves et al. 2016) the UNR (Argentina) is using the WebLab-Deusto platform to offer the students its VISIR remote lab. All these projects were granted by the EU within the Erasmus, Tempus, Leonardo, and Alfa programs.

WebLab-Deusto RLMS can be also used to integrate remote experiments into any LMS (Moodle, Sakai, Claroline, etc.) in a transparent (plug and play) way (as mentioned in Sect. 2.5). Using the WebLab-Deusto as a gateway, any institution can connect a remote experiment as an additional resource of the LMS, and under this tool the remote experiment can be accessed, tracked, etc. This was the main task of WebLab-Deusto in sLabs project (Sancristobal et al. 2012), granted by the Spanish Government in 2009; the same application was given in ePRAGMATIC project,Footnote 17 granted by EU in 2010 and in “Building an ecology of online labs” project,Footnote 18 granted by NSF (USA) in 2011. Currently, WebLab-Deusto is being used by different educational institutions to implement remote labs and remote experiments.

The Go-LabFootnote 19 project was granted by the EU in the FP7 and finished in 2016. One of the objectives of the project was to gather the remote experiments available in the world and offer them through a common platformFootnote 20 after an agreement with the owners of the experiments. The gateway4labs/Go-Lab Smart Gateway (as explained in Sect. 2.5) was designed for this task. Usually a remote experiment is included in a specific portal, but Go-Lab would like to offer this remote experiment through its own portal. When a user clicks on a remote experiment that is offered by the Go-Lab portal but it is stored in another portal, gateway4labs will make this link transparent for the user and the Go-Lab portal. gateway4Labs has been used to connect hundreds of labs to be used for thousands of teachers. At this moment, a new project called NextLab has been approved by EU in the H2020 program to continue with the main objectives of Go-Lab.

Currently, WebLab-Deusto RLMS is part of the PILAR project, granted by EU in the Erasmus+ program in 2016 (2016-1-ES01-KA203-025327), and it will be responsible of the federation of all the VISIR remote labs deployed in Europe. Federation is the highest level of integration of remote labs; under this approach, when a user creates a VISIR remote experiment, he/she will not know where it is going to be executed, in Austria, Spain, Portugal, or Sweden? This approach improves the scalability and the load balance, and it assures the availability of the lab if one of the VISIR is broken or not available. In the same line, in the proposal of the EOLES 2 project, WebLab-Deusto is expected to create a federation of remote labs designed and deployed in Europe and Maghreb. Under the EOLES federation, the different countries will be able to design and implement new engineering degrees.

Summing up, WebLab-Deusto RLMS can be used as a platform to integrate and offer remote experiments and remote labs or as a platform to help and facilitate another platform in integrating different remote experiments and remote labs.

7 LabsLand: A Spin-Off of WebLab-Deusto Aiming for Sustainability of the Service

The WebLab-Deusto team has started a spin-off called LabsLandFootnote 21 (Orduña et al. 2016). The goal of LabsLand is to provide a platform (Parker et al. 2016; Chase 2015) where different types of entities (schools, universities, research centers) can share their laboratories (using WebLab-Deusto or other systems) either free or for some price. The new platform uses the vision of the federation approach of WebLab-Deusto, and its aim is to create an ecosystem of providers and consumers of remote laboratories, as well as content providers.

The platform will continuously be tracking what laboratories are available and when, so it will be able to tell consumers what laboratories have actually been working during the last months. This way, providers of expensive equipment will be able to share the cost with other consumers, and consumers will know which providers they can trust and how reliable they are.

While in the beginning LabsLand counts with own equipment, most of the laboratories available in LabsLand will be property of the provider, and LabsLand will only manage the connections. The first pilots of LabsLand are running at the time of this writing.

8 Conclusions

WebLab-Deusto is a Remote Laboratory Management System (RLMS) that enables remote laboratory developers to create and manage laboratories focused on the particularities of the laboratories (and not on the management layers that can be managed by WebLab-Deusto). WebLab-Deusto provides a flexible architecture to this end: enabling developers coming from different backgrounds (e.g., those familiar with web technologies and those who are not) to create laboratories with the different approaches (managed and unmanaged) and benefit from all the features of WebLab-Deusto (authentication, authorization, analytics, scheduling, or integration in different learning tools).

A key feature of WebLab-Deusto is the way it shares laboratories, in a university-to-university basis rather than on a university-to-student basis. This flexible design enables a simpler customization by the administrators of each entity, since they see as local the external resources, and therefore they can easily assign who can access what remotely and locally.

On top of this experience, the WebLab-Deusto team has created LabsLand, a spin-off that provides a common marketplace for accesses to remote laboratories. As more entities join LabsLand for sharing their laboratories, more value will all the LabsLand network in an exponential trend as defined by the Reed’s law.