Reconfigurable web-interface remote lab for instrumentation and electronic learning

Engineering involves many areas of Science, and implies the explanation of many different theoretical concepts. Lab sessions are designed to reinforce those concepts, but generally they are not enough to cover all of them. Remote and virtual labs help this proposal. With them, students can put in practice and reinforce academic concepts at home. Specifically, Remote labs grant them access to lab equipment and configurations, impossible in other situations that request lecturer. In this work, a flexible configuration is presented, based on 2019 most popular programming languages (Python (for the back-end) and JavaScript (for the front-end)), for Remote Lab Sessions, with a minimum network privileges, scalable and reconfigurable. It is based on a Reception-Server, which hosts the User-database and the Shift Management, for use of Instrument-Servers, and controls the User data flow. These Instrument-Servers, host the instruments interfaces, the experience, and manage the connection with the instruments and different hardware involved. Users connect to Reception-Server, which uses a public IP address, and forward the Users to Instrument-Servers, on schedule reserved. This avoids the need for Instrument-Servers external access for, and protects the network, acting as firewall (only communications among Reception-Server and Instrument-Servers are allowed). The experiences are evaluated through a three-fold system, logging the User session, with a survey of interaction experience, and with a knowledge questionnaire related to the experience. An example of use is provided, in which the user experiences control of a DC power supply, throw GPIB using standard commands for programmable instruments (SCPI).


I. INTRODUCTION
Students Lab sessions constitute a key issue in Engineering subjects, due to the reinforcement. These sessions are time-constrained and generally this time is not enough to put in practice the theoretical concepts. In this point, remote labs do play an important role.
Remote laboratories make expensive instruments and specific configuration accessible to students outside of class hours, so they can practice and improve their skills and consequently complement the theoretical lessons.
However, in most situations, remote labs are based in commercial configurations as VISIR [1] [2], which is a matrix of connections and components, to simulate ProtoBoard. They are limited to their application. In other situations Remote labs are mixed with virtual labs, an example is Easy Java Simulations (EJS) [3]. This system is designed for simulations by software (virtual labs), despite of it can be connected to hardware to perform remote labs, using normally a privative specific designed connector.
Remote labs are no limited to commercial solution, as done in Labicom [4] [5], where a complete new system was designed. Server, client, solutions, all ad-hoc solutions are designed.
A compact solution is even provided with on-board computer systems [6], where a webserver is integrated in a raspberry-pi, with an Arduino as sensor interface.
All of them are only designed for a piece of the problem, in [7], a general study is done over Remote labs aimed to generate code and program devices. There, some of the subjects studied in this work are considered. From this work, the idea of a system structure, stable, scalable, and flexible, is exposed and demonstrated.
However, none of them shows a sufficiently flexible system, which can interact with any hardware, and shows a friendly web user interface. This paper focuses on the design, structure and function of a remote laboratory system, flexible enough to implement most laboratory experiences, for engineering learning, as Instrumentation, basic electronics or power electronics.
With that objective, servers are designed using the programming language Python, one of the most popular programming languages with several libraries, which allow interacting with almost any device. In addition, it can be set up as a web server, providing sufficient level of security and simplifying and ensuring data storage. The user interface is designed in HTML and JavaScript, introducing a fluid and asynchronous experience.
The article is structured as follows: in section II general lines and objectives of this project are given; then in section III the system structure is explained, followed in IV, where the relation with learning and examples are explained, the evaluation methods for learning outcomes are explained in section V, finally conclusions are given in section VI.
II. SYSTEM OBJECTIVE This work presents an online portal that grants remote access to the instruments to interested students through a shift management module. This proposal allows remote access and control of the instruments all day, every day of the week, except the physical session hours.
The shift management module controls the user session for each workstation (Instrument-Sever), limiting the session time to an hour and a half if there are users queued for the same Instrument-Sever. A user can only book a time slot, until it has been used (at this point, the penalty for not using a reserved time interval is not implemented, but is under development). In case that next time slot is free, user is asked for continue using the Instrument-Sever.
The instruments and equipment are not the same in all Instrument-Sever being worth mentioning that preconfigured scenarios can be loaded into each Instrument-Sever to test the different concepts and experiences. These experiences, for example, include the use and limits of experimental instruments, the interface for instrument controls, the use of instruments for measuring electronic experiences, etc.
With that, each Instrument-Sever could have a unique set of scenarios, related to the hardware connected to it.
III. SYSTEM STRUCTURE The proposed system structure is explained as follows. Each Instrument-Sever has two parts, a Web-Server and an Instrument-Connector prepared for all connected hardware. Back-end of the Web-Server and connector are implanted in python, and work together.
In most situations, Instrument-Connector would be a set of functions to link instrument's communication systems (GPIB bus, USB, Ethernet, etc.) with Web-Server. However, in some situations, it would need to process information, or establish a more complex communication with the devices, with a simple interface with the Web-Server (e.g., use an Arduino to measure temperature and humidity, take information from the serial port, and send temperature and humidity instead serial-data stream).
For the Web-Server, a specific Python Framework, Django with REST framework, is used. Django simplifies most of the server operations, including security issues, user login and logout, database table design, etc. It implements protections against common vulnerabilities and it is an active develop open source project. The REST framework increases Django's capabilities, creating an application programming interface (API), making data server data available (with a security layer) from the front-end (user interface), in an easy way. With all this, Instrument-Connector can be easily linked to the user interface.
For the User Experience, the front-end is designed to provide an attached camera video transmission, in addition to all the necessary controls and indicators, whose data-flow is managed by the Instrument-Connector through the API. This data flow is done in JavaScript, using "Asynchronous JavaScript and XML" (AJAX), which allows you to load / send a part of the website, without a complete loading of the site. A brief of this technology selection can be seen in Fig.1. As the user interface is independent of the Instrument-Connector, different interfaces can be designed, associated with different experiences. It is only necessary to implement the sequence of events. Most of the experiences would follow the same structure, show the instrument interface, show exercises, and ask for an answer (a value measure, a proper interaction, a text introduced, etc.) So same interface can be done for some similar experiences, and fulfil with a database, depending which experience is done.
Some scenarios or experiences may require test-boards, which work with the equipment connected to the Instrument-Server. In that situation, those experiences would only be available when those boards are connected.
There would be some Instrument-Servers, with different topology and instruments connected. In addition, they are in a private network. That makes it difficult for the user to connect to any Instrument-Server.
For the system to be scalable, Instrument-Server could be any system, but there would be some Instrument-Servers. That makes it difficult for the user to connect to the Instrument-Server.
Reception-Server is a single server, which can be accessed from the Internet. It redirects all traffic to each Instrument-server, according the shifts management. This server hosts the users database, the shifts management system, the main user interface and the information related all Instrument-Servers. However, it does not host any instrument.
For the user experience, the user must register on the Reception server, to be able to identify them univocally. If they are students, they will indicate a unique identifier as student, if a Learning Management Systems (LMS), as Moodle, is used, unique identifier used in LMS must be used. Once the user is registered, they can select a time slot for an Instrument-Server. During the selected time slot, the user has access to the web interface of the selected Instrument-Server. When the time interval ends, if the next interval is free, the user is asked to continue, if reserved, the connection ends and the instruments server reinitialize the instrument for the next session. From this moment, user can book other time slot, not before.
For the management experience, each Instrument-Server is registered on the Reception-Server. Registration implied set the internal IP of Instrument-Servers, and it's API-key. Once this is done, the instruments available in Instrument-Server, scenarios (or experiences), absolute availability time (time interval in which Instrument-Server is available), and other data of interest, are sent from the Instrument-Server to Internally, there is a lot of communication between each Instrument-Server and Reception-Server. First, the selected database is PostgreSQL; due to its capability to store more types of data, in particular JSON, as a data structure, useful for a structured user session login. Then, each user interaction involves an exchange of data. When the connection to Instrument-Server is established, each user interaction or data return is recorded in a session log, in addition to the id of the experience and the level of success of the session. When the connection ends, a summary is made. On the other side, in Reception-Server, when a user reserve a time-slot for an Instrument-Server, a verification is made. if the user does not exist in the Instrument-Server, it is created. Then, the reserved time for the user is indicated to the Instrument-Server to have the system ready. In addition, communication between servers is periodically tested. Registered Instrument-Servers have an Absolute Available time, if they do not respond at that time; a warning is given to the staff.
In addition, once the Instrument-Server has been registered in the Reception-Server, a SSH tunnel is prepared and tested. With this, the connection between the user, from outside the network, and the main web interface of the Instrument-Server, in the network is possible. In addition, the main Instrument-Server web interface is embedded in an Iframe in a Reception-Server site, so interaction with Reception Server is also possible. The Apache server can redirect the tunnel objectives to port 80, so the entire User experience will be at port 80 (or 443 for SSL).
With all this, as indicated above, Reception-Server only hosts administration systems and acts as a communication relay, connecting the user with the Instrument-Servers.
The Instrument-Servers host all hardware and experiences, and only receive information about users and reservations, when it is necessary. It has been selected a very powerful combination, however, programming Instrument-Servers requires a certain level of knowledge in Python and web-page markup and programming languages (CSS, HTML, JavaScript). Selected languages, Python and JavaScript, are the most popular languages in 2019 according to [8], [9], this implies active development, support, many packages available, lower probability of end of use soon, etc.
This structure configures a final scalable system, easy to introduce more Instrument-Servers, and stable, even if an Instrument Server suddenly disconnects. Even the Reception-Server can be backed up with another server (in this situation, first, all traffic will pass through a small server that points to the normal or backup Reception-Server, both sync all the time). All with only the requirement of a singleport (or two if normal and SSL connection are allowed) external access network from a single computer, which is common web ports 80/443. Structure is represented in Fig.2.
The system is not defined as open source, nonproprietary, or other license free tags, because Instrument-Connector could require proprietary libraries, not for commercial use, but most of JavaScript libraries (those used), are GNU, GPL or MIT, and DJANGO has a Creative Commons license and REST is authorized to use it with or without modifications by the copyright owners. Therefore, the core system has no blocking or license cost.

IV. INTEGRATION IN ENGINERRING LESSONS
Lab sessions in Engineering learning aim to reinforce the concepts explained in the theoretical sessions. However, in engineering, as in other university level education, not all theoretical concepts can be tested in the laboratory, as it would require too many laboratory sessions.
In addition, some of the demonstrations in the same field require the same type of equipment and can be organized, as can be done as a remote laboratory. E.g. Test frequency response in electronics requires a function generator, with a wide frequency range, and an oscilloscope. This can be used to determine the frequency response of the oscilloscope (if it is lower than the generation range of the generator), the frequency response of a component, such as an Operational Amplifier, the frequency response of a filter (active, passive, low-pass, band-pass, band-stop, high-pass, notch, etc.), or even frequency response of an electronic system, with poles and zeros. The required equipment and the procedure are the same, just change the element that is connected to them.
As an Instrument-Connector is designed for elements connected to any Instrument-Server, any operation with those elements can be performed during the experience. Following the previous example, function generator can be controlled to set or read amplitude, frequency, mode, waveform (where allowed), set the output impedance, etc. And the oscilloscope can be set or retrieve the current channels scales and time-base, cursors, measurements, mathematical mode, trigger configuration, etc.
With all these options available for the end user, experiments can be designed by associating actions for any question, or actions in web-interface. Each question or step in the experience saves interactions, number of attempts, and the time needed to solve each step during the user experience. This information is used for student evaluation and progress tracking. For the first implementation, an example of Standard Commands for Programmable Instruments (SCPI) (the base of the VISA protocol), using GPIB, is implemented to control a DC power supply. With this experience, students learn low-level communication with instruments, using standards. In all moment, the camera is streaming the front panel of the device. Fig. 3 show the main web interface of this experience.
As seen in the image, the camera streaming is the base of this experience. In this situation, an Agilent E3646A DC power supply is controlled. At right, there are Instrument Interface options. "Help" and "Programming Manual" open a pdf in a new tab. The "Help" pdf contains all the information related to: the use of the wed interface, a brief introduction of GPIB and SCPI, the remote lab experience procedure, and how to read the "Programming Manual". "Programming Manual" pdf has the info provided by the manufacturer; with all instructions for control the power source, using SCPI.
The GPIB communication used in this experience is basic, it only uses the commands "send", "receive", and "initialize", but these operations have few configuration parameters (instrument address, maximum reading length, timeout, etc.). They can be changed in "Config"; by default they have a set of values that make the experience possible. First, it is necessary to initialize the GPIB bus in order to establish the appropriate privileges for the PC as a controller. In this button a connection test has been implemented in addition to the initialization of the bus, sending a "*idn?", requesting for its name. If none response is taken connection error is generated, otherwise, the name of the instrument is shown in text-interface-box.
Each time a GPIB instruction is performed, a status value is returned, it is related to delivered status in communications (if message has been delivered or not). That value is shown in status.
When "Send" is clicked, the text in the text-interface-box is sent to the GPIB address, configured in "Config". When the User "Receive" is clicked, the response from the address is expected, with a maximum timeout indicated by "timeout" in "Settings". If it is not answered, an error is generated.
During this experience, it is usual to generate too many errors in the instrument. To know at any time if any action generates new errors, users must have the ability to remove errors and put the DC source in a known state. "Reset" button puts the source at the starting point, and "Remove errors" button, clears all error indications, without changing the configuration of the source. These buttons work by sending a set of instructions through the GPIB bus.
With this interface, users can answer all the questions/exercises proposed in the combo box. For the questions, users must give an answer in the answer text-box. For the exercises, it is indicated "Answer this exercise interacting with the instrument" in the answer text-box. In both situations, as soon as the user provides an appropriate response, the background of the combo box turns green for the actual exercise. When all items have a green background (succeeded), a pop-up window indicates that the experience is complete. The User can continue using the instrument during the reserved time.
When the experience is completed, or the reserved time ends, the evaluation exercises are activated. Although Instrument-Server hosts the evaluation exercises, like all the experience, in order the User can perform them outside the reserved time, they are transmitted to Reception-Server. From this moment, the User has available evaluation exercises in Reception-Server, and they can be done in a range of time (usually few days). Reception-Server sends the result of the evaluation exercises to the Instrument-Server, when it is done.
For students, once the experience is done, and when they have completed the evaluation exercises, the data are prepared for uploading to the LMS.
V. LEARNING RESULTS A remote lab experience is not easy to evaluate for a continuous improvement. In this work, the evaluation focuses on three aspects of the user: interaction, experience and learning.
First, as explained before, during the user experience, a lot of information is taken (time in each step or question, number of tries, steps passed, etc.). This provides an Then, the user experience is assessed via a quick survey from 1 to 5, where 1 is the lowest value and 5 the highest one to evaluate the camera quality, ease of use of the experience, the amount of time for slot assignment, and their overall evaluation of the experience.
Finally, students must take a short test, where the same concepts used in the experience are considered. Students should have learnt those concepts with the experience, as before, this assesses the student individually, and experience with the overall results.
The evaluation of student learning is carried out in two phases. First with its evolution in experience and finally with the test.

VI. CONCLUSSIONS
The proposed structure offers a very powerful and flexible solution for remote labs, aiding in engineering learning, easily scaling and reconfiguring, and with the capacity to implement almost any experience.
Only with a computer with external access and open common web interface ports, this system can work, which facilitates installation in a complex network system.
This system focuses on the interaction with instruments, and hardware, but since Instrument-Connector is a Python Script, it has many modules available to connect with many different systems or hardware. Even this work focuses on instrumentation and electronics, many lab experiences in the area of mechanics, power systems, control, or microinformatics use same standard hardware to create different experiences, so this system is perfectly compatible.
Additionally, a double evaluation is designed for the student learning, with their actions during the experience and with a knowledge test at the end of the experience.

ACKNOWLEDGMENT
The Spanish Ministry of Economy, Industry and Competitiveness [Grant No. supported this work TEC2016-