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

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

1. What is the purpose of this paper? The abstract is missing an explanation.
2. Please add information about hybrid solutions. A comparison of existing solutions with hybrid solutions is missing.
3. The limitations of the existing lab ecosystem are insufficiently explained. These limitations could be numerous. Please explain each of them.
4. Cross-compiling refers to creating executables for one architecture for another. There are insufficient examples. Please provide a detailed explanation and examples.
5. Remote code updates on microcontrollers refer to reprogramming the firmware to change the device's functionality or add new features. This allows modification of the device's operation without physical access. Please explain the remote code update methods and considerations in this paper.
6. No conclusions are claimed in this paper. It is difficult to reach a conclusion through the Discussion.
7. The number and content of the References are too small. Please refer to more recent references. 8. This paper is being rejected because it does not follow the required format and procedures. Please provide additional details.

Author Response

Review 1

1. What is the purpose of this paper? The abstract is missing an explanation.

The abstract was restructured and added the missing explanation.

New 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. Particularly, 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 was developed for a microprocessor laboratory course and 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.

 

2. Please add information about hybrid solutions. A comparison of existing solutions with hybrid solutions is missing.

The concept of hybrid was replaced with a more accurate concept: remote cross-compiled solution.  Hybrid can be confused with hybrid online laboratory type (local - remote).

 

3. The limitations of the existing lab ecosystem are insufficiently explained. These limitations could be numerous. Please explain each of them.

The following content about limitations was added in the Online Laboratories Section:

Limitations of remote laboratories and variations, which include 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. 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 and the ongoing working group IEEE P2834 - Standard for Secure and Trusted Learning Systems, 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.

 

4. Cross-compiling refers to creating executables for one architecture for another. There are insufficient examples. Please provide a detailed explanation and examples.

The cross-compiling process was explained, and 4 examples were added to the Introduction section.

Text added to Introduction:

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, 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 from Microchip allows the creation of embedded systems coding projects, targeting Programmable Intelligent Computer (PIC) or AVR family microcontrollers. Finally, Keil from ARM 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, an online tool that allows developers to generate and test optimized AI solutions, offers libraries and provides options to train customized AI models that can be directly transferred to embedded systems hardware. Similarly, Edge Impulse provides a cloud platform where developers can train AI models using user datasets to 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, thus keeping the equipment available to other users during code development and compilation phases. The 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, and 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.

 

5. Remote code updates on microcontrollers refer to reprogramming the firmware to change the device's functionality or add new features. This allows modification of the device's operation without physical access. Please explain the remote code update methods and considerations in this paper.

In subsection 3.2. Implementation of Cross-Compiling and Remote Code Uploading to a Microcontroller, was added a clarification of the type of program update used in this specific solution:

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.

 

6. No conclusions are claimed in this paper. It is difficult to reach a conclusion through the Discussion.

The Discussion section was renamed as 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 the 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.

The fact that MQTT is data-agnostic, meaning that the information transmitted in the message field can be in any format, and that the proposed system allows users to upload source code, 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 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 a larger emphasis on data collection and measurement, while in other laboratory activities, the coding component is more significant. This makes it harder to report specific values of improvement in availability.

Future work includes 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.

In addition, 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 batch when no other users are using the hardware.

 

 

7. The number and content of the References are too small. Please refer to more recent references.

 

The number of references increased from 16 to 28 and more current references were included.

 

8. This paper is being rejected because it does not follow the required format and procedures. Please provide additional details.

 

Additional details were added addressing the previous 7 comments.

 

 

Additional changes:

1. Diagrams were revised and generated in SVG format

 

2. Switch the order of MQTT and system architecture

 

3. Content added explaining SARL OLMS:

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 access
• The Session Manager module that keeps connected users' data for 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 has access to all available hardware and software resources in the system

Smart components of SARL include the Smart Adapter, 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.

Reviewer 2 Report

Comments and Suggestions for Authors

The manuscript proposes a hybrid remote laboratory system for microprocessor education that balances local code development with remote hardware access. While existing remote labs allow online interaction with physical hardware, they typically restrict access to one user at a time, limiting participation. The proposed system improves this by enabling users to lock the hardware only during debugging and testing, allowing code development to occur independently in local or remote environments. This approach avoids dependency on proprietary tools, enhances accessibility, and maintains hands-on learning and collaboration, thus offering a more scalable and user-friendly solution for remote microprocessor instruction. Some major issues have been identified as below:

 

1. While the authors claim that the proposed system is more scalable, some quantitative evaluations are expected to better support this point.
2. In fig. 2, it is not clear how the proposed hybrid local-online laboratory works. More descriptions and discussions are expected.
3. Fig. 7 and 8 illustrates the implementation of the lab station GUI. More justifications regarding the difference should be elaborated for better clarity.
4. Some references regarding IoT should be discussed in the related works:

1. Beyond the pixel world: A novel acoustic-based face anti-spoofing system for smartphones
2. Echoface: Acoustic sensor-based media attack detection for face authentication

Author Response

Review 2

1. While the authors claim that the proposed system is more scalable, some quantitative evaluations are expected to better support this point.

References for specific time savings were removed from the paper.

Text added to Conclusions section:

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 a larger emphasis on data collection and measurement, while in other laboratory activities, the coding component is more significant. This makes it harder to report specific values of improvement in availability.

 

2. In fig. 2, it is not clear how the proposed hybrid local-online laboratory works. More descriptions and discussions are expected.

Figure 2 was fixed adding the laboratory computer gateway that incorporates the functions of communication, cross compiling and video streaming.

 

3. 7 and 8 illustrates the implementation of the lab station GUI. More justifications regarding the difference should be elaborated for better clarity.

Clarification on the two figures reference and captions, and more detailed explanation of the components of each laboratory station were included.

 

4. Some references regarding IoT should be discussed in the related works

Beyond the pixel world: A novel acoustic-based face anti-spoofing system for smartphones

Echoface: Acoustic sensor-based media attack detection for face authentication

The two recommended references were added to the introduction section plus another two references for IoT based Online laboratories were added to the introduction section:

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 present 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, where 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 allows 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.

 

Additional changes:

1. Diagrams were revised and generated in SVG format

 

2. Switch the order of MQTT and system architecture

 

3. Content added explaining SARL OLMS:

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 access
• The Session Manager module that keeps connected users' data for 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 has access to all available hardware and software resources in the system

Smart components of SARL include the Smart Adapter, 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.

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

This paper has been accurately corrected for the errors identified by the reviewer, has been written in compliance with the format and procedures of the paper, and is of a satisfactory quality, so it is given an Accept rating.

Comments on the Quality of English Language

This paper has been accurately corrected for the errors identified by the reviewer, has been written in compliance with the format and procedures of the paper, and is of a satisfactory quality, so it is given an Accept rating.

Reviewer 2 Report

Comments and Suggestions for Authors

The authors have addressed all my concerns.