Availability Optimization of IoT-Based Online Laboratories: A Microprocessors Laboratory Implementation

Abstract

Online laboratories have emerged as a viable alternative for providing hands-on experience to engineering students, especially in fields related to computer, software, and electrical engineering. In particular, remote laboratories enable users to interact in real time with physical hardware via the internet. However, current remote laboratory systems often restrict access to a single user per session, limiting broader participation. Embedded systems laboratory activities have traditionally relied on in-person instruction and direct interaction with hardware, requiring significant time for code development, compilation, and hardware testing. Students typically spend an important portion of each session coding and compiling programs, with the remaining time dedicated to hardware implementation, data collection, and report preparation. This paper proposes a remote laboratory implementation that optimizes remote laboratory stations’ availability, allowing users to lock the system only during the project debugging and testing phases while freeing the remote laboratory station for other users during the code development phase. The implementation presented here was developed for a microprocessor laboratory course. It enables users to code the solution in their preferred local or remote environments, then upload the resulting source code to the remote laboratory hardware for cross-compiling, execution, and testing. This approach enhances usability, scalability, and accessibility while preserving the core benefits of hands-on experimentation and collaboration in online embedded systems education.

1. Introduction

Microprocessor programming laboratory activities are typically performed in a physical laboratory, where students receive support from instructors and/or laboratory assistants who provide recommendations and clarification on various aspects of the hardware and software being used.

In a typical laboratory class, students spend a significant portion of the laboratory session writing and compiling code. The remaining time is dedicated to hardware implementation, debugging the compiled code using a microcontroller and a computer, and testing and tuning the code to meet the requirements of the laboratory activity.

Online laboratories, particularly remote laboratories, offer users the ability to remotely control equipment and interact with it by modifying input parameters or code and receiving output data. These laboratories can be implemented using the advantages of Internet of Things (IoT) systems and communication protocols.

IoT applications are developed for a wide range of fields, including home automation, manufacturing, transportation, and education. IoT has an important role in securing system access. For example, in the application developed by [1], the authors presented a novel approach to prevent 2D face presentation attacks on facial authentication. They identified that RGB-based face anti-spoofing (FAS) models work well but often fail in new environments. The authors developed Echo-FAS, an acoustic-based system that uses only a speaker and microphone to capture 3D geometry and detect face liveness. Similarly, [2] proposed EchoFace, which implements the Echo-FAS approach in the context of mobile device authentication; using acoustic face liveness detection, the system can distinguish real faces from forged media with an accuracy of over 96%.

IoT technology also supports the implementation and operation of online laboratory systems, facilitating user interaction with remote laboratory equipment. For example, in [3], an RFID-Arduino system integrated with a web platform allowed for automated recording of student attendance and management of experiment data. Likewise, the RFID Pocket Lab IoT platform described in [4] provides portable laboratories that students can access in various environments while maintaining connectivity to a centralized resource server. IoT technology enables students to monitor experiments, access documentation, and receive real-time feedback data. Its connectivity enhances flexibility and efficiency in the utilization of laboratory resources, making IoT a critical component for the scalability, accessibility, and effectiveness of online laboratories.

One limitation of remote laboratory systems is that a user connected to a remote station typically blocks access for other users during a session. Some projects have addressed this issue by developing solutions that allow concurrent users to connect to a remote laboratory. The first such implementation was Virtual Instrument Systems In Reality (VISIR) [5]. VISIR allows users to build and measure circuits using real hardware. It provides a web-based interface in which users can design circuits with virtual instruments, submit them to be built and tested on a real circuit board through automated switching matrices, and receive real-time measurement results. The key for maximizing concurrent users is a relay-based switching matrix that can reconfigure circuits. This enables the platform to quickly set up and tear down circuits between user sessions with no manual intervention.

Companies such as LabsLand [6] offer “ultra-concurrent” laboratories, which are remote educational laboratories allowing experiments to be executed in real laboratory stations. Instead of live control, users access prerecorded experiment sessions which students can interact with via a web interface. This approach allows multiple users to conduct identical experiments at the same time, thereby avoiding appointment scheduling or waiting queues.

Another important consideration is that current online laboratory systems are often limited to proprietary tools and hardware provided by the system’s vendor, which are frequently the same companies that manufacture the hardware. This creates a dependency upon specific software and hardware licenses which users must acquire individually; alternatively, institutions need to acquire a class or campus license. One example is Quanser [7], which offers interactive laboratories that provide users with access to a collection of proprietary virtual hardware-based laboratory activities. These activities use Quanser hardware systems and can be accessed from desktops, laptops, or smart devices. With a similar approach, the company National Instruments (NI) [8] offers connectivity of their hardware through the use of LabVIEW, a graphical programming environment for test and measurement, as well as NI ELVIS, a virtual instrumentation suite for hands-on learning.

Some embedded systems and hardware providers offer access to cloud-based integrated development environments (IDEs) with which users can interact directly before transferring their programs to local or remote hardware. This approach facilitates project configuration, coding, and cross-compiling.

Cross-compilation is defined as the process of compiling a program on one computer system (the host) so that it can be executed on a different computer system (the target) with a different architecture. An example is the Arduino Cloud IDE [9], where users can code and cross-compile their software projects on the Arduino Cloud IDE and transfer the executable directly to an Arduino board or microcontroller. The MPLAB Xpress IDE [10] from Microchip [11] allows for the creation of embedded systems coding projects, targeting Programmable Intelligent Computer (PIC) or AVR family microcontrollers. Finally, Keil [12] from ARM [13] offers both cloud and desktop versions of its embedded systems IDE. It supports all of the ARM Cortex-M devices and includes services for project creation, compilation, and debugging.

In the context of Artificial Intelligence (AI), the ST Edge AI Developer Cloud [14] is an online tool that allows developers to generate and test optimized AI solutions, offering libraries and options to train customized AI models that can be directly transferred to embedded systems hardware. Similarly, Edge Impulse [15] provides a cloud platform in which developers can train AI models via user datasets. The models can then be run directly on hardware devices, including those with processing and memory constraints. Although these cloud services benefit developers, cloud-based IDEs still face challenges related to usability, security, and performance.

The proposed work presents a solution to increase remote laboratory hardware availability by allowing users to access the remote laboratory station only during the debugging and testing phases, thereby keeping the equipment available to other users during code development and compilation phases. The proposed system assumes that users have local or remote access to an IDE, including libraries for the specific microcontroller, sensors, actuators, and compilers for the target architecture. This setup allows users to develop and compile their solutions locally or in a cloud IDE, then connect to a synchronous live session on the remote laboratory to upload the source code, which is cross-compiled on the computer controlling the remote laboratory station and subsequently uploaded to the target microcontroller for testing and debugging.

2. Online Laboratories

Educational online laboratories are systems that allow students and educators to access and interact with laboratory equipment remotely even in the absence of physical access to laboratory facilities. These systems typically involve connecting laboratory hardware to computers with public Internet Protocol (IP) addresses, enabling the exchange of control commands and the transmission of real-time video feeds.

Online laboratories are evolving into essential components of modern education, particularly in STEM fields, offering flexible remote access to experimental learning while meeting institutional and industry requirements for security and data protection.

Online laboratories can be further classified into three types:

• Remote laboratories, which allow users to interact with real physical equipment via a network. In these systems, the hardware remains in a fixed location, but users can access and control it remotely.
• Virtual laboratories, which use software-based simulations to replicate laboratory experiments without involving real physical equipment. These laboratories are entirely computer-generated.
• Hybrid laboratories, which combine physical and/or online laboratory types. They may integrate physical types (e.g., on-site and mobile), online types (e.g., remote and virtual), or physical and online types. Hybrid labs support broader learning scenarios and maximize flexibility and resource usage [16].

Hybrid online laboratories may have interactions with physical laboratories. Physical laboratories can be classified according to their mode of access. On-site laboratories are fixed physical spaces located within institutions such as universities, research centers, or companies. Mobile laboratories, on the other hand, are deployed on movable platforms such as vehicles, boats, or aircraft. Due to their dynamic nature, they often incorporate geolocation and time stamping as part of their experimental data.

Limitations of remote laboratories along with variations such as real-time control of remote hardware have been identified over the years. These include issues of accessibility when laboratory experiences are constrained by limited controls, unclear operating instructions, and language barriers, among others. Additional limitations arise from the lack of variety in available laboratory experiences; most online laboratory experiments are restricted to access through a specific network or are not integrated into repositories where they can be easily found.

A lack of trustworthiness in terms of availability has also been noted, particularly with systems that are poorly maintained [17]. It is common to encounter systems that crash during experimentation or produce incorrect measurements due to insufficient maintenance and calibration of the instrumentation. The physical safety of the equipment is also critical, as in most cases laboratory equipment is left unattended, creating risks such as fire caused by electrical faults.

Standardization efforts such as IEEE 1876-2019—IEEE Standard for Networked Smart Learning Objects for Online Laboratories [18] and the ongoing working group IEEE P2834—Standard for Secure and Trusted Learning Systems [19] aim to ensure that online laboratory systems are interoperable and protect users’ data privacy. These standards provide guidelines for the development of robust, scalable, and trusted online learning environments.

2.1. Online Laboratory Management Systems

An Online Laboratory Management System (OLMS) is designed to centralize and coordinate access to online laboratory experiments. Such systems provide a comprehensive set of services and tools to manage the lifecycle of online laboratory activities, including:

• Authentication and authorization for verifying and controlling user access.
• Scheduling for assigning time slots to remote experiments, especially when resources are non-concurrent or shared across institutions.
• Resource management to oversee the use and availability of lab equipment or stations.
• Activity management, which offers authoring tools to define and organize lab activities and instructional content while aligning them with learning outcomes.

In both educational and industrial contexts, an OLMS enables institutions to integrate internal and external laboratory experiments into a unified platform. For example, one institution can provide its users with access to experiments hosted at another institution while retaining full control over scheduling, access permissions, and usage reporting.

In recent years, these systems have evolved into service-oriented architectures aimed at integrating distributed laboratory resources. They now offer functionalities such as remote control, visual experiment monitoring, online booking, and performance evaluation, playing a critical role in creating scalable, flexible, and collaborative online laboratory environments. These advantages are making them a foundational component of modern educational ecosystems [20].

2.2. Smart Adaptive Remote Laboratory (SARL)

In 2018, the Smart Adaptive Remote Laboratory (SARL) was proposed as a system that integrates features for adapting online laboratory experiments and activities according to user data collected by the system. These data include successfully completed activities, topics, time spent, and other metrics that can support assessment of the user’s level of experience. This automatic adaptation of the system based on user experience is reflected in the online laboratory’s Graphical User Interface (GUI), which provides a basic set of controls and activities for novice users while offering a more complex set of controls and activities to more experienced users. The SARL OLMS includes the following modules:

• The Authorization module, which controls which resources are accessed by each role in the system.
• The Authentication module, which ensures that only identified and authorized users can achieve access.
• The Session Manager module, which stores connected users’ data for the purpose of establishing, maintaining, and terminating user sessions.
• The Security Logger/Auditor module, which collects logs of user interactions and changes on system components.
• The Scheduler module, which provides functionality to reserve sessions with specific online laboratories.
• The Laboratory Experiment Composer module, which allows authorized users to create laboratory experiments based on the definitions of laboratory stations, activities, and assessment elements.
• The Laboratory Experiment Galleries module, where available online laboratory experiments are published.
• The Laboratory Resource Manager module, which has access to all available hardware and software resources in the system.

Smart components of SARL include the Smart Adapter module responsible for adapting the user’s interaction based on their experience. This module relies on the Learner Data Collection module for operation. The Learning Analytics element is used as an information source to generate usage metrics and reports. Finally, the Standards Integration module supports compatibility of the laboratory system with other OLMSs based on standard definitions, such as IEEE 1876-2019—IEEE Standard for Networked Smart Learning Objects for Online Laboratories. Figure 1 presents the modules of the SARL OLMS [21].

3. Design and Implementation of a Remote Laboratory

This section presents a prototype implementation of two online laboratories in which the coding and compiling tasks are performed by the user outside the synchronized session with the remote laboratory station. For this implementation, the approach of the Smart Adaptive Remote Laboratory (SARL) OLMS was used.

The proposed use case involves an Arduino-based remote laboratory station that utilizes an Arduino Nano Connect IoT board [22] in the remote laboratory station, the Arduino IDE [23] (local or cloud-based) to perform programming tasks and cross-compilation on the user side, and the Arduino CLI [24] to perform cross-compilation on the laboratory computer and upload of executable files to the remote laboratory station.

Arduino CLI is a solution that provides the tools needed to use some Arduino-compatible boards and platforms from the command line or machine interfaces. In addition to being a standalone tool, Arduino CLI is the base of the official Arduino development software, including Arduino IDE and Arduino Web Editor. The most commonly used Arduino CLI commands are presented in

Table 1. Arduino CLI service commands and description [24].

Command	Description
arduino-cli board	Commands for managing Arduino boards, including listing connected boards (board list) and identifying board details
arduino-cli compile	Compiles Arduino sketches for a specific board, using the Fully Qualified Board Name FQBN (Fully Qualified Board Name)
arduino-cli config	Manages Arduino-CLI configuration settings
arduino-cli core	Manages Arduino cores (platform definitions), including updating the index (core update-index) and installing cores (core install)
arduino-cli daemon	Run as a daemon on port: 50051
arduino-cli debug	Debug Arduino sketches
arduino-cli lib	Manages Arduino libraries, including installing (lib install), updating (lib update), and listing (lib list)
arduino-cli monitor	Opens a serial monitor connection to a connected Arduino board, allowing for communication and data exchange
arduino-cli sketch	Commands for managing Arduino sketches, including creating new sketches and listing existing ones
arduino-cli upload	Uploads compiled Arduino sketches to a connected board
arduino-cli update	Updates the index of available cores and libraries from the Arduino online repositories
arduino-cli upgrade	Upgrades installed cores and libraries to their latest versions

.

3.1. Architecture of the Proposed Design

The communication of commands used to control the remote laboratory is implemented using the MQTT standard protocol [25]. MQTT operates on a publish–subscribe architecture, and involves three primary actors in its framework: the broker, publisher, and subscriber.

The broker acts as the intermediary connecting the publisher and the subscriber, the publisher is responsible for sending messages to the broker using a specified topic, and the subscriber continuously listens to the broker for data published on a specific topic. Remote laboratory stations are MQTT publishers and subscribers [26]. The laboratory computer gateway acts as a broker, publisher, and subscriber.

Figure 2 presents the MQTT communication architecture. The diagram presents the proposed topology of the network of online laboratories, showing how one computer can manage the communication within a laboratory facility or institution that has connected multiple remote laboratory stations (nodes).

These local nodes in the institution do not have a public IP address to connect to the internet; instead, they use MQTT to communicate with an internet-capable node in the institution (laboratory computer gateway). At the same time, this computer has communication with the broker server, which is used by the users to interact with the remote laboratory stations.

The architecture is composed of the user, a local or cloud-based IDE, and the OLMS server, which contains the remote laboratory GUI and collects the user commands. A laboratory computer gateway receives messages from the users and directs the traffic to the destination remote laboratory station.

In the specific implementation described here, the laboratory computer gateway also manages the video streaming due to the memory and processing limitations of the remote laboratory station microcontroller. Figure 3 presents the architecture of the proposed remote laboratory system.

3.2. Implementation of Cross-Compiling and Remote Code Uploading to a Microcontroller

The approach for transmitting the user code, cross-compiling, and then uploading the executable to the remote laboratory station microcontroller is based on the use of MQTT messages and the Arduino CLI service.

The source code is transmitted as the payload (message field) of the MQTT message, taking advantage of the MQTT protocol’s content-agnostic nature. Because MQTT does not impose restrictions on data format, it enables the transmission of various types of content, including source code, within a single message. The sent message also includes the target remote laboratory station microcontroller in the “topic” field.

Figure 4 presents an example of an MQTT message executed in the OLMS server when the user uploads the file to the system. In this example, the Arduino “LED blinking” example source code is sent to the laboratory computer gateway targeting the remote laboratory “station1”.

The source code is received by the laboratory computer gateway, where a Python 3.13.5 script developed based on the paho, shellx, and subprocess libraries runs in the background, allowing the MQTT connection establishment and the reception of messages.

Figure 5 presents a simplified version of the Python script that supports a non-secure MQTT connection through port 1883, the broker activation, and the subscriptions as a subscriber to two different topics, “station1” and “station2”.

When the user publishes messages to either of these two topics, a shell script is triggered to perform the corresponding actions.

The compile and upload processes can be controlled through the Arduino CLI. The Arduino CLI can manage local Arduino projects on the remote laboratory station, including libraries and board types. A shell script is used to send commands to remote laboratory stations.

The script includes commands to compile, upload the compiled sketch to the target Arduino board, automatically navigate to the sketch directory, build the project, and upload it to the designated board and port.

For this specific implementation, the arduino-cli sketch, arduino-cli compile, and arduino-cli upload commands were included in the shell script file “script.sh”, which is executed on the laboratory computer gateway when it receives an MQTT message targeting one of its stations. The user source code is passed as a parameter received by the $msg variable, which is converted into text and included into an “.ino” file that is later cross-compiled and uploaded into the corresponding remote laboratory station microcontroller. Figure 6 presents the content of the script.

The program update performed on the remote laboratory microcontroller replaces the existing sketch in the board’s flash memory with the newly compiled code; it does not affect the firmware, bootloader, or any other low-level software present in the microcontroller.

The GUI implemented for this prototype included the remote laboratory station controls, the upload button used to send the source code to the corresponding remote laboratory station, and the live video streaming implemented to provide live feedback to the user about the current state of the experimentation process. For the prototype laboratories, two different stations were implemented.

Station 1 was composed of an Arduino Nano Connect RP 2040 microcontroller and an MG90S micro servo. The controls in the top part of Figure 7 allow the user to activate a preprogrammed rotation to the left and a rotation to the right of the servo motor. The text area below the controls is used to type/copy and upload a compatible Arduino code for testing. In the bottom part, the video streaming preview was implemented with the Real-Time Streaming Protocol (RTSP). Figure 7 presents the browser view of the Servo Motor Remote Laboratory Station (Station 1).

The second station we implemented was Station 2, composed of an Arduino Nano Connect RP2040 microcontroller, Actuonix L- 12-50-100-6R linear actuator [27], and HC-SR04 ultrasonic distance sensor [28].

The controls in the top part of Figure 8 allow the users to activate preprogrammed functions for turning two LEDS on and off and for moving the linear actuator in a predefined sequence of ten (10) readings, while the last two buttons are used to move the actuator 1 cm to the left or 1 cm to the right.

The current distance from the sensor to the black pad is also printed on the screen. The text area below the controls is used to type/copy and upload a compatible Arduino code for testing. The bottom part shows the video streaming based on RTSP. Figure 8 presents a browser view of the remote laboratory station GUI, station 2 (LEDs, distance sensor, and linear actuator station).

4. Conclusions and Future Work

The contribution of this work focuses on improving the availability of remote laboratory stations. The increase of availability is justified, as users will only occupy the remote laboratory station for testing their solutions and releasing the remote laboratory station during the coding phase.

Security concerns identified during the implementation of the remote laboratory system include the lack of validation of source code uploaded by users. This can create risks of hardware malfunction, including damage to the laboratory computer in charge of the cross-compilation process, the remote laboratory station microcontroller unit, or additional components such as sensors or actuators.

MQTT is data-agnostic, meaning that the information transmitted in the message field can be in any format; in addition, the proposed system allows users to upload source code. This opens up possibilities for attackers to inject malicious code into the system. A solution to this issue is to add validations for the type of code that users are allowed to upload. This can be implemented by performing a thorough inspection of the code content before cross-compilation and transmission to the remote laboratory station.

Quantitative data related to the time savings achieved by using the proposed strategy may vary depending on the type of laboratory activity. In some cases the coding phase is short, with more emphasis on data collection and measurement, while in other laboratory activities the coding component is more significant. This makes it difficult to report specific values of improvement in availability.

Future work will include adding cross-compiling and upload features for multiple programming languages and multiple microcontroller units. This will contribute to increasing the compatibility and flexibility of the remote laboratory station.

Another idea to improve the availability of the system is to implement batch execution of multiple predefined tests. In this scenario, the user uploads the program and the remote laboratory station runs the test cases in batches when no other users are using the hardware.