Models of Collaborative Remote Laboratories and Integration with Learning Environments

Development of remote laboratories in academic settings has been held back because of the lack of standardization of technology, processes, operation and their integration with formal educational environments. Remote laboratories are used in educational settings for a variety of reasons, for instance, when the equipment is not available in the physical laboratory; when the physical laboratory space available is not sufficient to, either, set up the experiments or permit access to all on-site students in the course; or when the teacher needs to provide online laboratory experiences to students taking courses via distance education. Centers have been forming platforms that grant remote access to a collection of physical experiments that provide alternatives to educational institutions to reduce budgets of not only equipment purchases but also other expenses, such as, people, space, maintenance, and electricity consumption. This paper offers a taxonomy and examples of types of laboratories and hybrid combinations, and proposes Unified Modeling Language (UML) models for remote laboratories incorporating access models for collaborative user roles in the educational context that support synchronous and asynchronous formats in learning environments. The need for development of adaptive interfaces for remote laboratories based on difficulty level and demonstrated user knowledge is presented. Finally, the paper proposes a scheme of virtualization of the infrastructure and an adaptive scheme of assisted remote laboratories where part of the experience is carried out by the user (student) and part is assisted by the system (teacher avatar) that is able to act as a team mate for the students during the experimentation process.


INTRODUCTION
Remote laboratories have been under development for more than 15 years. In 2002 Hamza, et al. [1] evaluated alternatives to physical laboratories used in engineering education, including simulation and remote laboratories. Since then, research laboratories and companies have improved the quality of the experience with remote laboratories by increasing infrastructure technology available to build remote experiments. The band width, processing capacity, video codification algorithms, new and more versatile controllers and hardware devices [2], repositories [3] and portals to access the remote experiments are some of the elements that have been improved drastically in a relatively short period of time.
Providing Laboratory as a Service (LaaS) [4,5] has been proposed for companies, research and laboratories centers to develop and implement modular remote laboratories accordingly to the demands of the user. However, without standards and models for implementation of remote laboratories, it is difficult to guarantee minimum levels of quality, reliability, safety, security, etc., and these services will be implemented without interoperability considerations.
Within the educational context, there is an important demand for these types of services. Remote laboratories play an important role in academic areas, such as Physics, Chemistry, Biology, Medicine, and Engineering. There are two main elements in the educational context that remote laboratories providers need to take in account. First, the roles of the users: the users can be teachers, administrators or students, each will use the services in different ways. Secondly, integration and interoperability are important when it is desired to combine and integrate these services with educational platforms. Due to the need for integration, contextualization and interoperability, the IEEE Education Society has formed the IEEE-SA P1876 ™ Working Group (Standard on Networked Smart Learning Objects for Online Laboratories) [6] to develop the standard that will define the architectures and implementation processes.
The next sections present terminology and concepts, propose UML models for laboratory taxonomy, for remote laboratory, and for user collaboration roles possible in remote laboratories to facilitate understanding uses and configurations the standard needs to support and to document a reference for developers and users in the academic context. Innovative schemes for adaptive interfaces, assisted experimentation and resource sharing are then presented. The last section presents conclusions and future work.

II. BASIC CONCEPTS IN REMOTE LABORATORIES
Online laboratories can be either remote laboratories or virtual laboratories. Remote laboratories use real physical laboratories that are capable of being accessed through a network. The instruments can be accessed, monitored and controlled at a distance. Virtual laboratories, on the other hand, are basically simulations that mimic the behaviors of real laboratory artifacts. The results of the virtual experimentation process should be similar to those obtained in a real laboratory, but results are mostly based on calculations and mathematical formulas. Most advanced virtual laboratories include in its data processing information of previous experimentations made in physical laboratories, creating a more realistic and reliable environment that takes into account behavior of real components [7]. Fig. 1 illustrates the interface for an existing remote laboratory at North American Network of Science Labs Online (NANSLO) [8] having the capacity of using four cameras, each having six pre-configured positions to get a better sense of the environment, as well as focus on the display of each instrument. Notice also the controls on the interface for remote adjustments of variables such as: panning and zooming of the cameras and setting current and voltage. This interface additionally has on the top left an indicator showing temperature of the equipment. In this particular experiment a heater must be turned on and the instruments must reach a certain temperature for the instrumentation to operate optimally. A pop-up interface allows the user to request access to view the instruments and one student to control the instrumentation.

III. TAXONOMY OF REMOTE LABS
Physical laboratories are commonly part of government institutions, companies and/or educational institutions. There are two types of physical laboratories: on-site traditional laboratories, sometimes called real laboratories, constructed in a fixed physical place, and mobile laboratories, which are hosted on vehicles, such as boats, airplanes, cars (for climate monitoring, surface sensing as example). The mobile type of laboratories use additional important variables, such as the current geographical position and time stamp as part of each experimental data result. Fig. 2 presents a classification of remote laboratories [3], based on the location of the experiment and the location of the experimenter.
In Fig. 3, the proposed model uses Unified Modeling Language (UML) notation [9] to classify possibly types of laboratories, illustrating the types of relations that can be occur among these. A Laboratory can be Physical, Online or Hybrid. The Physical laboratory can be On-Site or Mobile, while the Online laboratory can be Remote or Virtual. A Hybrid laboratory can be composed of a combination of Physical laboratories (e.g., an on-site and a mobile laboratory), or a combination of Online laboratories (e.g., a remote and a virtual laboratory), or a combination of a Physical and an Online laboratory. Some possible set of combination are described with examples in the next section.

IV. CONFIGURATIONS OF HYBRID LABORATORIES
Hybrid laboratories are created by combining physical and/or online laboratories. The following are some possible configurations and examples of these laboratories.
A) Local access to real laboratory (on-site) with online access to a virtual laboratory. In this configuration the users work on equipment in a physical facility but also simulate some processes using virtual laboratories available externally. An example of this is: a group of students working on the topic of energy in the physics lab, and at the same time, using an open educational resource (OER) [10,11] virtual laboratory available in the University of Colorado's PhET platform [12] to simulate the kinetic and potential energy in the movement of a skate board, as shown in Fig. 4. B) Local access to real laboratory (on-site) with local access to a virtual laboratory. This is very similar situation to the previous one, but in this case the virtual  laboratory is available locally. An example of this is: a group of students working in the construction of an aerodynamic vehicle. Previous to constructing it physically, they decide to create a simulation on their computer to know the exact effect of the wind on a particular design of the vehicle. C) Local access to mobile laboratory and online access to a virtual laboratory. In this configuration the users work in a mobile laboratory but also simulate some processes using virtual laboratories available via the PAPER

MODELS OF COLLABORATIVE REMOTE LABORATORIES AND INTEGRATION WITH LEARNING ENVIRONMENTS
internet. An example of this is: a group of meteorologists measuring climate variables in a mobile laboratory vehicle and also at the same time, running a climate prediction model available on a remote server [13]. D) Local access to mobile laboratory with local access to a virtual laboratory. This is very similar situation to the previous one, but in this case the virtual laboratory is also local. Referencing the previous example, the only difference is that the meteorologist would run the climate simulation model from a program installed on their local computer. E) Remote access to mobile and online access to a virtual laboratory. This particular configuration is commonly used when people are not physically inside the mobile laboratory. For example, if the mobile laboratory is created to perform deep water experiments in the ocean, it is very possible that the instrumentation needs to be accessed remotely by a use from a boat. Additionally, the user can have the support of simulations available externally on the boat to be completely sure of some instructions given to the instruments in the underwater mobile laboratory. F) Remote access to mobile and local access to a virtual laboratory. This is very similar situation to the previous one, but in this case the simulations are locally stored. G) Remote access to real laboratory (on-site) and remote access to a virtual laboratory. In this configuration the users work in a remote laboratory and also simulate some processes using virtual laboratories available externally. An example of this is: the design process of circuit, the students decided first to simulate the circuit using PartSim web platform [14] to verify the maximum power supported by the circuit, and with this data then students determine the type of components, such as capacitor and resistors, that are needed for the real circuit in the remote laboratory session, see Fig 5. H) Remote access to real laboratory (on-site) and local access to a virtual laboratory. This is very similar situation to the previous one, but in this case the virtual laboratory is also local; for instance, if the students of the previous situation use the stand alone software OrCAD [15] instead of using PartSim, see Fig. 6.

V. PROPOSED MODEL OF A REMOTE LABORATORY
This section develops a model of the typical architecture of distributed remote laboratories based on the work of Tawfik, Salzmann, Gillet and Lowe who proposed delivering remote labs using the Laboratory as a Service (LaaS) approach [16].
The proposed model for the Remote Laboratory, shown in Fig. 7, has three layers. First, the Client Layer provides the user an interface to request and interact with remote lab experiments by communicating with the second layer, RemoteLabServer Layer. This layer provides the Client layer access to a remote laboratory using three modules: AccessManager, responsible for validating the identity and authorization rights of the user. The second module, the Scheduler, provides the services related to the management of the user appointments and the validation of the availability of a specific experiment (resource). The Scheduler works with the third   . Virtual Laboratory for circuit simulation from local platform OrCAD [15] module, called Resource, which implements the searching service over the indexed list of resources using the metadata associated with each resource. Once the Scheduler has identified resource availability, the RemoteLabServer sends a confirmation and access token to the User. The Third layer is related to the PhysicalLaboratory, which implements a centralized Administrator module responsible for the com-PAPER MODELS OF COLLABORATIVE REMOTE LABORATORIES AND INTEGRATION WITH LEARNING ENVIRONMENTS munications with the RemoteLabServer and is also responsible of performing administrative activities, such as: update the new resources, report changes of schedules originating at the physical site (for maintenance, etc.), and activate alerts when security or safety constraints occur in the use of the equipment. An Experiment is managed by an Administrator, and consists of Equipment including zero or more instances of Camera, Sensor, and Actuator, and a Controller, which allows the user to view, acquire date and control parameters of the Equipment.

VI. MODELS OF COLLABORATIVE ROLES IN REMOTE LABORATORIES
During the last two decades companies have developed very interesting products to provide experimental environments to industry, universities and schools in topics such as: physics, chemistry, electronic systems among others, but most of them are limited to provide remote access to physical resources, and are not concerned with user feedback nor how the user interactions information generated could be useful to teachers and students in the learning processes.
Other common problems of remote laboratories include that users cannot use the same resource at the same time. For instance, in the case of laboratories related with control systems, commonly students need to schedule a turn to use the control infrastructure remotely in an individual mode because the actuators cannot execute actions from different users at the same time. The case of sensor is different because reading a specific sensor can be broadcast to a group of concurrent users.
Collaborative remote laboratories allow a specific laboratory to be simultaneously used by a group of users. Callaghan, Harkin, McGinnity and Maguire in 2007 [17] proposed a technological architecture to support collaboration in remote labs. In a collaborative scheme, users must have specific roles which identify the type of activities that each user can do, for example, only one of the members of the group can give instructions to the actuators, while other members will have the job of monitoring the sensors, etc. Due to the risks that this scheme can generate for the security and safety of the laboratory equipment and facilities, it is important to generate mechanisms to automate the assigning of roles and restrict the activities of each user to the specified actions for their assigned role.
Schumacher, Fernandez-Buglioni, Hybertson, Buschmann and Sommerlad published a book of Security Patterns [18], software design patterns that have been validated and standardized for implementing security. Their patterns include one for Role Based Access Control (RBAC) which defines the structure of roles for accessing a protected object, as seen in the UML diagram shown in Fig. 8. The administrator defines a set of standard roles and their rights to protected objects. The appropriate Role is then assigned to users and according to their access needs, the User is granted the Right to access a set of activities to interact with a ProtectionObject inside the system, i.e., an object to which there should be restricted access through the use of an Authoriza-tion_rule granting access through a Right (e.g., read, write). In the educational context, the roles may vary depending of the structure of the institution, commonly defined roles are teacher, student, grader, lab assistant and administrator. It is also possible to give more than one role to one user, for example the teacher of the course can act as a Teacher and/or as the Administrator of the Laboratory, as seen in Fig 9. The Administrator determines which experiments the students in the course sessions will be assigned remotely. The Teacher requests access to the lab for each Student on the class list. The Teacher role can be made more specific to include the Instructor role, who monitors the progress of the students, grants extensions and determines final grade, and the Coordinator, who can be the grader or lab assistant assigned to the Instructor to record student participation and lab completion and handle student questions on the remote lab experiments or access. The Coordinator could also be the staff or faculty person that needs access to sample work and grades for compiling documentation for accreditation purpose. The Student role reflects the constraint that the controls of the equipment in the laboratory can only be manipulated PAPER MODELS OF COLLABORATIVE REMOTE LABORATORIES AND INTEGRATION WITH LEARNING ENVIRONMENTS by one User at a time by defining more specific roles for students, such as: • Leader -responsible for coordinating all the requests and use of the experiment (resources, security, time, control, etc.) for the student group • Implementer -responsible for codifying the instructions in the software platform • Executer -responsible for sending the instructions to the equipment, and • Recorder -responsible for monitoring and recording the results of the experiment.
Other roles can be defined according to the specific type of laboratory.

VII. PROPOSED MODEL OF REMOTE LABORATORY INTEGRATED WITH LEARNING ENVIRONMENT
One of the shortcomings of the current remote laboratory implementation is the lack of integration with learning platforms. This section proposes a UML model integrating the remote laboratory with a learning environment that uses a Learning Management Systems (LMS) [19,20] and an educational standard [21] to communicate between the remote laboratory servers and the learning environment. In this architecture it is important to describe two important standards; the first is Learning Tools Interoperability (LTI) [22], a standard created by the Instructional Management Systems (IMS) Global Learning Consortium [23], with the primary purpose of connecting learning systems, such as a LMS, with external service tools in a standard way across learning platforms. This standard uses the Extensible Markup Language (XML) to allow the interoperability between both systems. The second standard is experience Apilication Program Interface (xAPI) [24], also known as the Tin Can API, an e-learning software specification that allows learning systems to communicate each other in order to record and track learning experiences. Fig. 10 shows the proposed UML model illustrating how a learning environment, such as LMS, could be integrated to the remote laboratories infrastructure.
In this model, access control is implemented using RBAC, having two main roles: teacher and student, in the case of the teacher, they are responsible of the administration of the course, is the only one that can request and schedule resources (experiments), and grant resource access to the students. Teachers also can assign different roles to every member of a group of students to use one remote laboratory in a collaborative way within the schedule class time.
The students will have available the laboratory access inside a learning unit for their course within the LMS using LTI, and in this case, within a scheduled class meeting. Access to the laboratory experiments should be configured previously by the teacher for students in the course. During the session of experimentation with the laboratory all important interactions (from the point of view of the teacher), will be stored in the Learner Record Store (LRS) system. Students also can find, in the same learning environment, the guide with instructions to perform the experiment and to make the report with the results gathered during the experimentation process.
In another variation with additional methods and details, the model can be extended to allow the teacher to assign the lab experiment and a range of time within which it must be completed, and also allow the student to request the scheduling of the exact time of their lab experience. This variation would be more appropriate in a distance learning environment that is asynchronous.
The high level class diagram, shown in Fig. 11, shows the classes of the remote laboratories network at the software level. It shows how users, in this case students, teacher and administrators, can interact with the remote laboratories available through an LMS platform using the standards or simply connecting directly to the service. Adaptive user interfaces have been applied in a variety of software applications, such as commercial web applications, educational and research applications, among others. In the context of virtual laboratories some advances have been done adapting the interface of the simulations and allowing the user to personalize the interface [25].
In the case of remote laboratories, recent work has shown how web interfaces can be created that adjust the services requested by the users [26,27,28]. Also this concept can be applied by using educational standards. Through the use of standards it is possible to inform the remote laboratory of the mastery level of the student and the complexity of the experiment, and the laboratory can block or hide some of the controls, restricting the view of part of the controls or blocking the option of configuring some others. In this way, students can start using a very simplified version of the remote laboratories experiment based on the difficulty level and their knowledge. As their knowledge and mastery level increase, the remote laboratory can turn on more controls, increasing the complexity of the experiment. Information must flow in both directions, from the student profile to the remote laboratory and vice versa, keeping updated the student level and the remote laboratory interface.
Assisted remote laboratories consist of a configuration in which part of the experience is made by the user and part is made by the system, this approach can be implemented using intelligent tutoring systems [29]. A virtual tutor can be trained using expert knowledge, or the system can learn by mimicking and processing the teacher behav-ior (teacher avatar), the intelligent tutor must identify the level of student knowledge and act as an expert team mate, doing at the beginning with most of the experiment, but later giving the student more and more responsibility. This can be mapped as a level of trust. The more the student and avatar practice together, the higher will be the level of trust of that the student can perform increasingly complex tasks. Students can learn from seeing how the intelligent tutor solves the problems. This kind of systems has been used in contexts such as: e-learning environments, video games, and training simulation software.
This tutor or teacher avatar can make use of the adaptive interfaces described previously to control or block the students' access to some parts of the laboratories.
Remote laboratories present a new technological challenge in terms of access and resources sharing, permitting many users to access the same equipment at the same time. This is something that for now seems to be not possible, taking into account that the equipment unit composed by actuators, sensors, cameras and the control unit is accessed sequentially. To help solve part of this restriction of the physical equipment, some advances made in the fields of networks communication systems and cloud computing architectures can be adopted in the remote laboratories implementation.
One proposed approach is the concept of multiplexing of connections. This would consist in allowing multiple users to share reading the sensors during the experimentation process. This would require the control system to remember the current state of the experiment for each of the users connected and allow each individually, in a short window of time, to manipulate the actuators according to their programs.

PAPER MODELS OF COLLABORATIVE REMOTE LABORATORIES AND INTEGRATION WITH LEARNING ENVIRONMENTS
A second approach recalls the concept of operating systems virtualization [30] which allows the system hardware to run multiple instances of different operating systems concurrently. This concept can be applied to remote laboratories virtualizing the control unit as an instance of a larger infrastructure that can provide an equivalent computational power and the memory required to run the experiment. This approach generates additional challenges, such as: the emulation of the specific architecture of the control unit, e.g. Programmable Logic Controller (PLC), Microprocessor, Peripheral Interface Controller (PIC), and Field-Programmable Gate Array (FPGA); and the management of the available resources that can be assigned to a user in time windows.

IX. CONCLUSIONS AND FUTURE WORK
Remote Laboratories are growing fast and with the implementation of educational standards and novel approaches, such as adaptive remote laboratories and intelligent systems, the use in an education context will grow, benefitting communities that do not have the resources to offer the laboratory resources to their students. This paper presents the need for establishing standards and models for educational use of remote laboratories that are compatible with established learning environments and LMS. Various efforts toward standardization, such as the IEEE Education Society e-learning standards currently under development, and the proposed Laboratories as a Service approach, would benefit from development of detailed models and design patterns that describe the requirements to developers and users, allowing composition of more complex collaborative interactions with remote laboratories, and more interoperable architectures that would better support the learning process and requirements and yield learning analytics currently not available.
This paper proposes a UML model classifying the different types of laboratories, presents examples of hybrid configurations that the model would support, extends the model to include a learning environment, and proposes a model for remote laboratory access roles that have the flexibility of supporting synchronous and asynchronous formats.
Future work planned includes the development of a pattern language, patterns with static and dynamic models and variations that detail in depth the scenarios of possible interactions with remote laboratories, especially in the context of education. New developments in technology make possible new ways to interact with and use remote labs, it is important to develop new standards, not only to define technological aspects, but also include the educational context and the pedagogical aspects. Security aspects are important in the implementation of remote laboratories, risks could be generated due to bad use of the laboratory, intrusion of viruses or malware, impersonation of users remotely, and many other threats inherent to systems distributed through any type of networks. Safety concerns, due to the possibility of exceeding operational requirements of the equipment, need to be addressed. Reliability of the remote laboratories can be improved through more complex scheduling algorithms that take into account the mean-time-to-failure and maintenance requirements such as battery or expendable materials replacement. Patterns showing how to integrate security, safety and other non-functional concerns need to be developed.