A Fully Open Source Remote Laboratory for Practical Learning

Abstract

Nowadays, communication and web services are part of our lives, including education, and e-learning applications are used more and more. However, teaching in engineering sciences requires an important amount of practical experiments. Hence, remote laboratories are an attractive solution, offering new tools for both teachers and learners. Our objective is to propose a fully open source remote laboratory for generic practice, in all fields of engineering education or applied sciences. This work is based on an open source Supervisory Control and a Data Acquisition platform programmed with Python. Interoperability is one of the main issues considered here to ensure a wide compatibility with multi-communication protocols and multi-instruments used in practical labwork.

1. Introduction

One of the main goals of remote laboratories (e-labs) is to extend the possibilities of practical experimentation in scientific academic degrees. Moreover, post-secondary student profiles are diverse but well suited to new Information Technology. Another important point is related to student cohort massification in higher education [1,2] that induces the need to carry out pedagogical innovation [3]. To answer these issues, new trends in engineering education deal with distance education to complete traditional face-to-face education [4]. Remote laboratory has been used for more than twenty years now [5] and is still massively used for learning technologies, as shown by numerous publications these last years. These remote laboratories led to many benefits for both teacher and student: all-time accessibility, enhanced learning processes, practical example in classroom lecture, etc [6]. Thus, they are well adapted to flexible student’s digital environment of today. Nevertheless, the remote laboratory is much more difficult to implement than a virtual laboratory that is often associated with remote laboratory. Virtual laboratory is only a computer based model for simulations, which is cheaper and easier to implement as well as to share [7]. Accordingly, developments to improve standardization, simplicity, and cost of remote laboratory are important research issues.

The state of the art is the focus for two main topics: open source remote control laboratory and open source Supervisory Control And Data Acquisition (SCADA). As remote laboratory is mainly developed by university or training center, the open source and publication aspects are automatically considered, for instance, [8] or [9] and more recently [10,11]. In [12], a remote laboratory for control education is implemented using common communication and programming languages: HTML 5, JavaScript for client side, JSON for data transfer, and PHP/MysSQL for the server side. Everything is open source designed, even the hardware part with Arduino boards. The project SEITI RMlab is programmed with the same logic (HTML5, JSON, etc.) running an electromechanical practical work [13]. Another open source project is presented in [14] where a solar tracking system using Raspberry Pi and open source hardware cards are used to obtain a low cost remote system. The same solutions are used in a remote smart grid demonstrator [15]. In the other way, solution spreading to collaborators is common. Some projects have already validated their solution like the UNED network [7] or the PEMCWebLab [16] and more recently Lab@Home [17] to only cite some examples.

On the other hand, our project takes inspiration from the SCADA system and particularly in open source SCADA. Proprietary software is expensive and there is a problem of interoperability with infrastructures or devices. The open source SCADA platform, Thinger.IO, designed for Internet of Things (IoT), is implemented in [15,18]; however, this solution is not entirely free, even if the cost is acceptable. In fact, low or medium size industries face the same issues than engineering education centers: for example, ref. [19] works on Object Linking and Embedding (OLE) for process control (OPC) with a Python language. The work of [20] demonstrates an important effort to work on sensors/actuators with open source software and hardware, and they use the free tool Easy Java and JavaScript Simulations (EJS) to carry out their experiment.

To introduce the intersection of remote laboratory and SCADA system literature, some smart grid applications have been considered because these projects intermix SCADA architecture and energy monitoring on the education laboratory. These applications have an important need for control and supervision of power generation and use. The Smart Electric Power System (SEPS) Laboratory [21] is an example; however, it is programmed with LabVIEW, namely a proprietary solution. In the same manner, a remote laboratory based on SCADA architecture has been proposed by [22] using Programmable Logic Controller (PLC) to manage the laboratory and a Visual Studio with an ASP.NET solution for the web interface.

Otherwise, ref. [23] have demonstrated a low cost SCADA system with open source hardware (Arduino) and common programming language (HTML5, JavaScript, and PHP) on a microgrid test bench for academic and research applications. Similarly to open source SCADA, interoperability issue has been studied in remote laboratories to carry out standardization on different communication protocols, programming software, and data exchange [24].

In relation to the state of the art, it appears that there is not a real open source system (entirely open) and all developments are specifically dedicated for one system or experimental laboratory. Most of the time, proprietary software is used (e.g., Matlab or LabVIEW). Some authors have already addressed low cost and open source solution, but, to the best of our knowledge, our work is one of the first projects to work on fully open source and modular solution to offer a wide interoperability. In this logic, software (server and controls) and hardware solution have been designed to ensure interoperability with hardware on the server side and with software on both the server side and client side.

This article is organized as follows: Section 2.1 describes our solution for remote laboratory where the architecture overview is presented. Then, a description of the open source programming solutions of the remote laboratory in reference to the SCADA system and communications is provided. Hardware elements of our solution are explained. Section 3.1 briefly describes two kinds of practical laboratory work that can be implemented in the plugin concept and illustrates our approach with an application to electronics labwork. Finally, key results are summarized and future studies are introduced.

2. Materials and Methods

2.1. System Description

The project, Laborem, has evolved since 2017 from a LabVIEW based solution [25] to an open source solution [26,27,28].

Laborem concerns both learners and teachers and has multiple applications in education as graphically summarized in Figure 1. Remote laboratory can be a solution for learners with motor or auditory disabilities or learners in continuing education, and it completes and enhances online courses with laboratories. To offer access to Laborem to the public with visual disabilities, we will plan to offer Braille support and large font size option for the web HMI. Dropping out students might prefer not to work in a common class environment. More precisely, Laborem is used with undergraduate students which are very receptive to distant control and a game-like scenario. For teachers, Laborem is implemented both for entire laboratory courses, or to prepare practical work before face-to-face practical work. It represents a new educational tool to mix practice with theory, as well as to offer a multi support enhanced learning process.

Another important point is to provide simplified access to the laboratory, independently of opening hours, and, in particular, each student can work at his own pace. Only one test bench is necessary to perform a wide range of practical works within one course; this represents a low-cost solution and the opportunity to share with other educational centers.

The initial prototype of Laborem used a technically advanced solution running on the Windows Server operating system. The proprietary LabVIEW software from National Instruments was used to program and to create web remote access, which allows for control benchmark equipment and to exploit data results. The software cost, the powerful server needed, and the nonstandard protocol used by LabVIEW to communicate data through internet led us to develop an entirely new system to migrate to an open source and light software.

Table 1. Comparison between former Laborem and the current solution.

Issues	Laborem 2017	Laborem 2019
Cost	Expensive: LabVIEW, powerful server, NI data acquisition system	Cheap: Raspberry Pi as a server, Python programming, free drivers
Pedagogical efficiency	High: used with student (tests since 2012) 40 students each year	Possibly higher: better integration with Moodle, not yet tested
Availability and Access	Not easy, nonstandard web communication	Full compatibility with web browser (HTML, JavaScript)
Various equipment compatibility	Excellent, based on NI Database (proprietary)	Good with PyScada and VISA protocols (open source)
E-lab network	None	Under construction, network with Burkina Faso, Germany, Spain

compares the original Laborem version with the current version, highlighting the differences and evolution. To summarize our solution, firstly, the cost of the solution is reduced by utilizing open source software, a low cost server (Raspberry Pi) and developing our acquisition card. Secondly, the interface compatibility is improved employing standard web protocols while good hardware compatibility is kept thanks to open source and widely used libraries. With this solution, new perspectives were opened such as integration with a Learning Management System (LMS) and creation of an e-lab network to share practical works between universities.

The Laborem architecture is centered on the server, here a Raspberry Pi which hosts the web Human Machine Interface (HMI) accessible by a student. It communicates with the motherboard to select which circuit will be tested. A robotic arm is used for circuit modification, two cameras mimic student’s eyes to see all the test bench equipment and ongoing measurements. The overview is presented in Figure 2.

2.2. Software Architecture

2.2.1. Programming Language

The core software is PyScada, a free and open source SCADA application written in Python with a web HMI [29].

The high-level free and open source Python framework used is Django, which allows for creating database-driven web applications. Algorithms, settings, and data models are written in Python. The Django framework core can be seen as a Model-View-Controller (MVC) architecture. As described in Figure 3, this Python based MVC architecture uses an Object-Relational Mapper (ORM) to manage the data model and interact with the database, an URL dispatcher to receive the HTTP requests, and a web template system to generate dynamic HTML5 pages. Alongside HTML5, the application uses JavaScript and CSS (Cascading Style Sheets) to enable interactive web pages.

The SCADA system with HTML5 HMI allows students to interact with various instruments and view the data on any recent web browser, independently of the operating system of the final user.

In PyScada, all the processes are working asynchronously and communicate through the database. It means that, on one side, the HMI queries the values to display and writes the user actions to the database. On the other side, scripts that send and request data to the equipment also query the database to know the user action. Alongside these, scripts feed the database with instrument answers relative to the original request. These processes are managed by a master process named the scheduler.

The Raspberry Pi 3 [30], which is a single board computer (SBC), replaces the previous personal computer (PC) that was used as server. It is an all-in-one, low-cost hardware solution, shared by a large community, so it is an interesting and widely chosen solution, for example [8,12,19,31] use a Raspberry, whereas [7] uses a BeagleBone Black board.

2.2.2. Communication Protocols

In order to have interoperability with many instruments, the system has to be compatible with several communication protocols (VISA, Modbus, etc.) and several hardware interfaces (USB, Serial, Ethernet, etc.). PyScada offers a wide range of protocols for SCADA systems based on the wide Python open source community and its useful applications such as PyUSB, PySerial, PyVISA, and PyModbus. All the protocols implemented and used are graphically illustrated in Figure 4.

The developed solution is a multi-protocol and multi-instrument system. It works like a bank of instruments where one can easily choose the instruments connected to the Raspberry Pi independently of the hardware interface used. For instance, one can switch between two oscilloscopes, HP 54603B and Tektronix MDO3014, using GPIB and USB connection, respectively, where each instrument has a dedicated handler file. Each handler has the same functions which are adapted to capabilities of each model and brand specific SCPI instructions (Standard Commands for Programmable Instruments). For example, the Tektronix MDO3014 is able to give directly the phase between two signals, whereas, for the HP 54603B, it is necessary to digitize these two signals and therefore use a NumPy function in order to compute the phase.

2.3. Modular Hardware

The hardware setup on the server side is shown in Figure 5.

2.3.1. Modular Motherboard

The motherboard interconnects laboratory devices and practical workbench, such as device under test (DUT). It receives and manages all experiment information. Each plug is a DUT and can be easily replaced by the teacher to adapt the scenario to the learner’s profile. The learners will have access to 16 different DUT to achieve their work. For example, DUT in electronics can be a low-pass filter, a high-pass filter, a band-pass filter, an active Sallen–Key filter, a Wien bridge, etc. A multiplexer enables the plug selection according to server request. A specific power card supplies the energy required for the motherboard and the plugs from single phase 230–110 Vac to several Direct Current (DC) power supplies (+15 V, −15 V, 5 V and 3.3 V). The block diagram of the motherboard is described in Figure 6.

The Printed Circuit Board (PCB) was firstly designed with Multisim and Ultiboard (National Instruments proprietary software), but new ongoing projects are made with KiCad (open source software). All of the PCB designs are open source. Connectors and plugs are designed in PCI Express logic. This is a well-known electronic standard, it simplifies PCB design, and reduces cost because it only uses one connector (female). In addition, this solution is widely used and has a good mechanical resistance. This choice ensures hardware interoperability with a simple connector that fits all applications and robustness for a long life utilization.

The motherboard is designed to limit human needs. The teacher needs to set up the configuration of the practical workbench at the beginning of a new course and to select the 16 different plugs that can be used by students. The only specification is that all plugs need to have the same Input/Output (I/O) configuration to work concurrently. Then, the I/O configuration is specified in the Laborem administration interface by the teacher, selecting for each of the 12 I/O ports the type of the connection. It could be, for example: a channel for oscilloscope, another for the function generator and also General Purpose Inputs/Outputs (GPIO) to interact with the Raspberry. The teacher can save various I/O configurations that match different groups of plugs to easily reuse them in a future utilization.

2.3.2. Generic Plugs

Plugs are designed for all kinds of applications. The DC power supplies from the motherboard are available inside plugs to be fully compatible with TTL or CMOS logics in digital electronics (+5 V and +3.3 V, respectively). The 15 V symmetric supply is used for analog signals that can be positive and negative and typically used with Operational Amplifiers. Moreover, the 15 V can be used for a local power supply if more power is required, for instance to locally heat a temperature sensor. Finally, 12 General Purpose Inputs/Outputs (GPIO), both analog and digital, are available and can be implemented to build experimental workbench or circuit. The plug schematics is described in Figure 7.

Similarly to the motherboard, plugs are designed to minimize physical human actions; however, it is important to remote control devices within plugs. Thus, these controlled devices mimic student actions to remotely modify the DUT, to activate/deactivate part of an electronic circuit, to adjust a load or to vary a motor speed, etc. For instance, a practical work using a Wheatstone bridge has been implemented with digital potentiometer as already presented at [28]; in this case, the plug is designed as follows:

• Analog:

  −

  input signal (waveform generator)

  −

  output signal (oscilloscope)

  −

  electrical component wired between 2 I/O (resistance, capacitor)

• Digital:

  −

  I2C bus command for digital potentiometer

  −

  logic signal (low/high) to control switches.

To conclude this section about the hardware, all elements are stored in a “Laborem Box”, an open source plastic box designed with Solidworks and realized by a 3D printer in our fablab at the University of Pau, Anglet, France. Then, pictures of the all-in-one Laborem box are presented in Figure 8. The approximate size is 20 cm (width), 25 cm (length), and 10 cm (thickness).

3. Results

3.1. Category of Labwork Applications

3.1.1. Small Signals

In Laborem architecture, plugs are sorted into two categories: the first one is related to small signals where everything is on the plug: circuits, DUT, and remote controlled components. Practical experimentation takes place within plugs. This family concerns, for instance, the following topics: basic electronics, instrumentation, industrial data processing such as microcontroller application, automation, etc. These experimentations must be supplied by the “low” power supplies available (+/−15 V maximum as mentioned above) and with a current limited to 1 Ampere.

3.1.2. Large or External Signals

Some other applications have specific prerequisites; this second plug category corresponds to a “large signal” relative to higher power (several Amperes or hundreds of Volt) and “external signal” for applied science laboratories. These applications need conditioning circuits like voltage level adaptation for interoperability between DUT and control/acquisition signal (digital or analog). This specific requirement is common and has already been addressed in [20].

Power applications use high voltage and high current, so measurements are more complicated. For instance, voltage can be measured thanks to a potential divider (capacitive or resistive divider), transformer, etc. The current is usually measured with a current transformer, Hall effect sensor, shunt resistor, or current probe. The conditioning circuit will be embedded in a specific plug.

In the same manner, other applied science experiments need a conditioning board too, as mechanical laboratory work needs torque, speed, pressure sensors, etc. In that case, plugs are linked with the motherboard and the SBC through GPIO and serial bus.

In that case, local Data Acquisition (DAQ) circuits can be implemented and will communicate directly with the server, without using instruments like digital multimeter or oscilloscopes. This operating mode is close to other proposals in the literature, such as [7,10,11,12,23].

3.2. Applications to Electronics Labwork

3.2.1. Implementation for an Electronics Filtering Course

Laborem has been dedicated to electronic filtering courses, and the first practical work available is therefore about this subject. The Laborem client’s side view is illustrated in Figure 9 where students can select which circuit they are going to experiment.

For instance, measurements have been performed on a band-pass active filter among one of the 16 available plugs. The frequency analysis (Bode Diagram) is illustrated in Figure 10, and Figure 11 is the PCB plug picture of the filter.

3.2.2. Pedagogical Scenario

The pedagogical scenario is based on a game-like approach. It includes a treasure hunt and a Top10 of the best measurements. The typical scenario contains introduction lessons (pre-requisite and new theory), quizzes, remote experiments, and a final exam to evaluate knowledge. Like in e-games, the four basic concepts are: level (beginner, medium, advanced), number of lives given (equivalent to number of allowed repetitions), score, or mark obtained for an activity and time spent in the activity. Moreover, an adaptive scenario is implemented to improve learner immersion and motivation in the student learning process as described in Figure 12.

The LMS plans different paths depending on student’s results during the sequence of the scenario, allowing teachers to modify the route. For instance, Top 10 activity corresponds to questions about the measured value of typical parameters or specific points. Depending on the correctness of the answer, typically its precision: 5%, 20%, or out of interval, the learner will get more or less points which will be updated in the Top 10. These questions can also be used for partial or quick assessment in preparation to face-to-face experimental laboratory.

The Laborem platform is accessible through any recent web browser. During the development phase, access is limited to the users of Université de Pau. They have easy access to the remote laboratory with the server IP address. The platform authentication is validated by a Django credential or by the university Central Authentication Service (CAS). With the integration of the Laborem platform in a remote laboratory network, access will be opened to other universities. Each student connected to the web page is ranked in a waiting list. The oldest user (known as the “worker”) in the list is credited with 5 min to work on the Laborem platform before to let the next user the access to manipulate. If there are other users waiting to access the platform (known as the “viewers”), the “worker” has limited time to use the platform. The “viewers” can see “worker” actions, their ranks in the waiting queue, and the waiting time left. After studying a device, student can answer questions and climb in the user Top 10 ranking. Teachers can have special rights such as moving any other user to the bottom of the waiting list, changing the list of available devices or the list of experiences that students can access, adding or removing questions and answers, adjusting working duration, etc. Usability improvements are done yearly using the results of a survey filled by students.

In the former version, students had the same basic scenario adapted to learner level, evaluated with a quiz at the beginning. Therefore, Moodle is well adapted to this complex scenario, and it is currently under implementation to offer multiple and independent routes. In the case of measuring misinterpretation or test failures, the student is repositioned at the course beginning by the supervisor. Thus, the teacher can follow student’s progress and specially help a student in difficulty. A first quiz evaluation is performed just after the introductory lecture, prerequisite of a previous course and basic elements to guide the learner to the most adapted path (e.g., more or less difficult choice of an active filter). This treasure hunt scenario needs numerous exchanges between the remote laboratory and the LMS, as well as several quiz evaluations. Quizzes are used for in-progress formative tests, practical interpretation, and summative tests.

4. Discussion

Finally, the main reason to stick to real experimental equipment such as Oscilloscope, DC source, Arbitrary Function Generator (AFG), Digital Multimeter (DMM) is explained in the following. Even if this equipment is expensive, students prefer to use real measurement devices as if they were in a traditional face-to-face work. All measurement devices can be implemented while they are remotely programmable. Similarly, these devices are much more accurate than an instrumentation solution with a micro-controller through analog to digital converter (ADC) and a signal processing. They are fully configurable (impedance, scale, DC/AC coupling, etc.) too. The main objective is to train a student to control remote devices as they will have to deal with them in their future professional life. Remote working is currently being used more and more. Remote control is common in the evolution of industry, Industry 4.0, as shown by [32] to improve factory efficiency and for remote maintenance by [33]. Engineering education centers need to take part of this evolution.

Power consumption measurement has been performed to evaluate consumption, for the adequate design of our power supply board, and to know the consumption of each device. Power consumption values of all equipment in our remote laboratory are shown in

Table 2. Remote laboratory consumption.

Hardware	Power (W)
Core system: Raspberry Pi3, external devices (2 webcams, external USB hard drive), motherboard, supply card (relay) and plug with DUT running	9 W
All other equipment: DC source, AFG, DMM, Oscilloscope, etc.	120 W
Total power consumption	129 W

. These measurements were performed while the system was running. The overall consumption of the core system is less than 10 W. Then, equipment shall be added; however, it depends on the test bench and the laboratory type. Our test bench is composed of a DC source (ISO-Tech, IPS4303S), a waveform generator (Tektronix, AFG1022), a Digital Multimeter (Keithley, DMM 2110), and an oscilloscope (Tektronix, MDO3014).

5. Conclusions

The proposed solution is an entirely open source remote laboratory, not only for the software part but also for the hardware. The interoperability issue is a priority to offer a large compatibility and guarantee an easy adaptation for various applications. All Protocols and hardware interfaces compatible with Laborem are illustrated in Figure 13.

Laborem represents an all included solution to practical work for undergraduate students (Bachelor of Engineering, B.Eng or Bachelor of Science, B.Sc.). In Laborem experiments related to electronics, most of the undergraduate programs have already been done. Future work will be focused on extending to other subjects such as power electronics, applied sciences, energy, mechanical engineering, and renewable energy thanks to the generic and modular hardware concept proposed. Concerning the software part, future works are conducted to increase our database of protocols such as BACnet. This special feature will allow for work on energy monitoring of buildings based on multiple electrical sensors exchange based on the open source developed solution.

In relation to the open source and modular proposition, the aim is to unite universities to create a global network. This has been already started with a first partner in Germany at the Technische Universität Berlin (TU Berlin) and two more in Burkina Faso at the University Joseph KI-ZERBO (Ouagadougou) in Autumn 2020.

Finally, all developments are available on the GitHub platform: under “PyScada-Laborem” for the software [34] and under “Laborem-hardware” for electronics and mechanical designs [35]. Thus, everyone can download and implement their own open source solutions for remote laboratories.