Laboratory work has long been identified as an important element of undergraduate degree courses in many disciplines, especially engineering and the applied sciences [ 1
], [ 2
]. With the increasing availability of advanced telecommunications infrastructure and associated access to internet-based applications, there has been a recent increase in the development of remote laboratories [ 3
]. The facilities typically provide internet-based access for students to monitor and/or control physical laboratory equipment which is located remotely from the student. Current implementations vary in sophistication, ranging from the simple ability to monitor output data from a single piece of equipment, through to systems which provide queuing and automated allocation of students to one of a set of multiple laboratory rigs with complex video/audio/data monitoring and control. As an illustration, Fig. 1
shows the remote laboratory facility in the Faculty of Engineering at the University of Technology, Sydney. This facility currently supports six different experiments, with multiple sets of equipment for each experiment. Access occurs through the internet using a combination of a web interface and a remote desktop connecting to an experiment server, and is managed through an arbitrator system which either allocates equipment to students, or places the student in a queue if all equipment is currently in use.
Fig. 1. UTS Remote Laboratory Facility ( http://remotelabs.eng.uts.edu.au). (a) Physical equipment; (b) student interface to the Beam Deflection Experiment.
There are several motivating factors supporting the use or remote laboratories, including cost, security, reliability, flexibility and convenience [ 4
]. The earlier era of remote laboratory development saw most effort directed at technical development— preoccupations included experimenting with technologies for real-time audio and video streaming in an effort to overcome bandwidth limitations while ensuring service quality, and dealing successfully with the arbitration of multiple simultaneous connections to shared online laboratory apparatus and equipment.
To a significant extent, many of these issues have been successfully overcome. Continuous, reliable, and high quality services have been maintained for much of the past decade [ 4
], [ 5
]. This progress has resulted in a shift in the focus of development effort away from technical refinement. Recent trends have focused upon enriching the nature of the student interaction (for example, including support for student-student collaboration and student-teacher interaction). In parallel, there have been moves toward developing a clearer understanding of the pedagogic aspects related to conducting laboratory work remotely and indeed a more reflective consideration of the laboratory learning context in general (both conventional laboratories where students are proximal to the equipment they're using as well as remote laboratories) and the place of experiment simulation [ 6
In Section 2, we discuss related work and the current situation with regard to remote laboratories. In Section 3, we look at contemporary architectures using two examples to illustrate current approaches. In Section 4, we discuss the way in which these systems typically utilize internet technologies, the constraints which this imposes, how this influences the nature of the laboratory experience, and the implications of future trends in internet technologies.
A standpoint advocating that all undergraduate practical experimentation should (or even could) be carried out remotely would be difficult to defend and is not the objective here. Rather, the evaluation of existing implementations has demonstrated that, when used in the right context, remote laboratories can provide significant advantages over conventional proximal laboratories [ 3
], [ 6
], [ 7
]. While there is not yet any significant research data on remote laboratory cost comparisons, anecdotal evidence indicates that operating
costs can be significantly reduced. This is in part due to the equipment and apparatus being held in a physically secure environment with tightly constrained access that limits either intentional or unintentional misuse. This reduction in attrition and "wear and tear" on the equipment, an entrenched characteristic of proximal laboratories, means that more elaborate, expensive, and/or delicate experiments can be constructed. This in turn makes possible student exposure to systems that might not have otherwise been afforded them. The result is that when viewed on a macroscale, more rather than less experimentation by students becomes possible. Additionally, the convenience and flexibility of being able to complete laboratory experiments remotely tends to fit well within the complex lifestyle of the contemporary undergraduate student—it is as welcome among the student body which is comprised of full-time or part-time "on campus" students as it is with those that are distance mode. A final advantage which remote laboratories offer is that they present a capability of interinstitutional sharing of laboratory infrastructure and resources [ 5
]. The potential benefits to students are enormous and profound, but it requires a global view if it is to be realized.
Having accepted that there are considerable "logistical" benefits of remote laboratories—flexibility, cost, and resource sharing—attention needs to be given to the impact that a change to remote laboratories has on student learning outcomes. It is clear that the environment in which learning takes place, whether online or face to face, involves a complex array of factors that influence learner satisfaction and achievement [ 8
]. These factors include the relationships between the user and the technology, the instructor and students, and the relationships among the students [ 9
]. This is of particular relevance when considering the evolution of the internet to incorporate increasing support for interactivity and social collaboration.
As a part of the adoption process of remote laboratories into engineering curricula, various authors have made attempts to determine an appropriate list of "quality indicators" for the online laboratory experience. This has been approached primarily from two perspectives, the first being relative to the expectations of students (e.g., [ 10
], [ 11
]) and the latter being driven by course or subject content. These include the level and speed of interaction, clear articulation of expectations, timeliness of feedback, and access. In highlighting such factors and relating them to the remote access mode, it is important to note that implicit to this discussion is how these factors are influenced by the nature of internet technologies. From a broader perspective, simply referring to the literature to determine an appropriate answer is inconclusive. On one hand, there is the proposition that there is no significant difference between the educational outcomes from students who performed an experiment remotely, versus those who carried out the experiment proximal to the equipment and apparatus [ 12
]. The alternate view however argues that students' performances on different criteria can vary depending upon the form of access used and that indeed some outcomes appear to be enhanced by nonproximal access modes, while others seem to be degraded [ 6
], [ 13
So, having recognized that the nature of the learning outcomes arising from laboratory experiences has a complex relationship with the characteristics of the interaction modality, it is worth considering the way in which the technologies which are used affect the nature of the interaction. From this point we can then consider the most appropriate way to leverage emerging technologies.
3. Remote Laboratory Architectures
A design challenge in the practical development of a remote laboratory is to identify an architecture which can provide appropriate access to the remote hardware. In the simplest form, the remote laboratory may be a single experiment, with a custom-built web-based interface which may optionally include reporting of measurement data and audio/visual feedback. A more sophisticated facility may involve multiple sets of equipment, multiple experiments, and many users. To illustrate the challenges presented by the design of remote laboratory systems, we will consider the architecture of two contemporary systems: the UTS remote laboratory facility and the MIT iLabs.
These systems were chosen because they are both mature architectures, but represent substantially different architectures for supporting remote access to physical systems. Publicly accessible examples of laboratories built using both architectures are available, as is documentation detailing the architectures.
Within the UTS remote laboratory facility [ 14
], there are currently six collections of significantly different experimental equipment [ 4
], [ 15
], [ 16
• Microcontroller design (12 Embedded Operating System Experiments);
• Beam Deflection (10 Beam Behavior Experiments);
• Automation (5 PLC Experiments);
• Dynamics and Control (3 Coupled Water-Tanks Experiments);
• Programmable Hardware design (5 FPGA Experiments);
• Structures Design (3 shaker-table platform experiments).
The UTS architecture was developed to provide flexibility and extensibility, as well as the ability to manage multiple sets of equipment. A key aim was to ensure that all experiments can be accessed from any networked computer without having to install additional software, including control applications, onto the remote computer (since students may be accessing the laboratory from computers on which they have limited user permissions). The resultant architecture is shown in Fig. 2
a. A remote user logs in through a web browser (with authentication managed by an arbitrator) and requests access to a set of equipment. The arbitrator allocates apparatus to students from the pool of unused devices, queuing allocation requests when necessary. The student is then provided, through the Web interface, audio/visual monitoring of the equipment. In order to support control of the equipment (and the differing user interfaces associated with the control applications), the arbitrator boots a Windows virtual machine on a master server (using VMware) and associates this virtual machine with the relevant equipment. The student creates a remote desktop connection to this virtual machine, runs the control application, and controls the equipment. The control application is, therefore, running on the master server (not on the remote user's computer) but with the user interface being presented on the remote machine. Fig. 1
b shows the resultant hybrid interface. When a session of use is completed by a student, the arbitrator reclaims the apparatus, reinitializes it, and returns the device to the free pool. This architecture means that the only software required on the client side is a Web browser and a remote desktop client. This architecture is now underpinning the LabShare project—an Au$3.8 million project, titled " National Support for Laboratory Resource Sharing
," which is funded partially through the Australian Government's Diversity and Structural Adjustment Fund—though it is expected that the resultant architecture for this project will be an optimal combination of the UTS architecture, the iLabs architecture, and others.
Fig. 2. Typical Remote Laboratory Architectures: (a) UTS Remote Laboratory Facility; (b) iLabs Architecture (from http://icampus.mit.edu/iLabs/architecture/).
Contrasting with the UTS architecture is the more distributed architecture used for the MIT iLabs ( Fig. 2
b). Here, the equipment is managed by Lab servers, and authentication and access is moderated by a service broker. There are two forms of experiment in this configuration: batched and interactive. With batched experiments, the student interacts indirectly with an experiment through a client on their remote machine, which passes the student-configured experimental parameters to the service broker, which in turn communicates to a laboratory server which executes the experiment. Ultimately, the results are returned to the client once complete. In this form of experiment, there is no interaction between the client and the experiment while it is executing. Students receive results only on completion of the experiment (indeed they need not even remain logged in while the experiment request is queued or executing). Conversely, interactive experiments allow direct communication between a student's client and the laboratory server. The architecture incorporates a modified Interactive Service Broker (ISB) which provides a scheduling feature and (at the appropriate time) establishes communications between the student-side client and the Laboratory server. The most recent iLabs Shared Architecture (ISA) merges the batched and interactive elements into a single architecture.
These two exemplar architectures have different strengths. For example, the iLabs Shared Architecture has very strong support for access booking, distributed and federated user account management, and is inherently scalable. Conversely, the UTS remote laboratory architecture strongly supports access queues, equipment management, and arbitration of access to multiple identical rigs. Neither has good support (in the current production releases) for aspects such as multiuser collaboration and communication, integration with third-party learning management systems (LMS), or virtual world interfaces—though ongoing research is addressing some of these aspects (see, for example, [ 17
While there are many other architectures which have also been adopted in supporting remote laboratories, they typically are either simpler than the above (e.g., a single downloaded client application communicating with a single experiment) or share similar characteristics to either or both of the above examples. The exceptions are where other approaches address those aspects mentioned above as weakness of the UTS remote laboratories and iLabs. These will be discussed in more detail as appropriate later in the paper.
4. Utilization of Technology and Educational Implications
Existing remote laboratory systems utilize the internet in diverse ways. In considering this it is useful to return to the core relationships which exist during student laboratory experimentation. As discussed previously, this includes the relationships between the student and the equipment, between students, and between the instructor and students [ 9
4.1 Supporting the Student-Equipment Relationship
At the core of the interaction between a single student and remote equipment is consideration of the way in which a student engages with that equipment. There are two primary dimensions to this interaction: the extent of the live interactivity, and the richness of the representation of the experimental reality which is exposed to the student.
In terms of live interactivity, the iLabs Shared Architecture illustrated support for different ends of this spectrum. In batch mode, students submitted their experimental parameters and the experiment request was then queued to be carried out remotely and asynchronously. This form of interaction places relatively low demands on the technology—bandwidth is generally not an issue (there is no requirement for live monitoring) and there is no direct interaction between the student and experiment. Conversely, interactive experiments involve live synchronous interaction with the experiment. Where the monitoring involves video and/or audio, this implies streaming of the media and adaptation of the system to varying bandwidth. In the case of the UTS remote laboratories, this is addressed through providing the student with a choice of media access: streamed video in various formats and autorefreshed image snapshots. One of the key issues in student monitoring of the experiment involves how experiment events are handled. When monitoring occurs through a Web browser, the inherent "pull" model of the Web (i.e., interactions are initiated by the client) means that creative approaches have been developed for passing information from the experiment server to the user with minimal latency. The simplest approach is to use automatic webpage refreshes—but this tends to be somewhat cumbersome. An alternative is to use separate client applications which establish a continuous communication with the experiment. This solution however requires the installation of user-side applications, which may not always be feasible. The emergence of AJAX technologies has provided an alternative to these approaches, whereby finer grained data updates within the web view of the experiment can be achieved. AJAX allows client-side code, running in the browser, to support dynamic adaptation of the interface and content updates without requiring the delay of a full webpage reload.
The second element of the user-experiment interaction relates to the perceived "reality" of the experiment. Previous research [ 18
] has considered the significance of experimental verisimilitude and how this affects student engagement. In particular, it has been shown that students' perception of whether the experiment is "real" or a simulation can affect their willingness to accept the experimental results as valid and hence affects the learning outcomes. Interestingly, the requirement for experimental verisimilitude varies during the student engagement. Lindsay et al. [ 18
], [ 19
] refer to the concepts of "establishment reality" (i.e., the initial establishment of the students' acceptance of the reality of the experiment) and "maintenance reality" (i.e., maintaining the students' acceptance of the experimental reality). This has implications for the nature of the experimental interface and how technology might be used in constructing it. For example, we have anecdotally noted that inclusion of video information showing the broader context of the experiment within the laboratory can significantly affect the establishment reality. An interesting comment came from a student who noted that it wasn't until he overheard several technical staff members talking near the equipment, that he realized the equipment was real rather than a simulation (despite the quality of the streaming video which was included in the interface).
As part of evaluating the student-equipment relationship in more detail, student survey data were collected from the students who used the UTS remote PLC laboratory and the remote water-level control laboratory during 2006 [ 20
]. Students were asked to respond to a series of questions on a 10 point Likert scale—including two that related to the student-equipment relationship: Question 4: Didn't you feel a degree of isolation between the physical system and you? And Question 6: While you were using the remote PLC lab, did you feel like you were operating real equipment? The survey results [ 20
] show average agreement values of 5.4 or higher for Question 4 and 6.8 or higher for Question 6, indicating that students did feel a degree of isolation from the physical equipment, but in general they believe they are using real equipment. The survey also addressed a number of other issues related to the student-equipment relationship, such as responses to the nature of the video and audio feedback. These results are well reported in [ 20
Another key aspect is the integration of remote laboratories with existing third-party LMS—particularly with respect to aspects such as data exchange and automated assessment. Most existing LMSs support rich functionality, much of which is highly relevant to remote laboratories. Examples of this include grade tracking, collaboration tools, management of assessment tasks, etc. Many LMSs also provide interface mechanisms that allow programmatic interaction from other applications. It is, therefore, feasible to implement aspects such as: automated transfer of experimental results into students' LMS accounts; utilization of the LMS collaboration tools to support interaction within the experiment; assessment activities that involve live interaction with laboratories; and adaptation of the experiment based on information on the student provided from the LMS. For examples of work in this area, see [ 21
], [ 22
4.2 Supporting the Student-Student Relationship
It has long been accepted that peer collaboration can play a major role in affecting student learning outcomes. Also, the majority of conventional (proximal) laboratory exercises are group based (though admittedly this may often have been for logistical rather than pedagogic reasons). Despite this, the vast majority of current remote laboratories provide limited support for student collaboration, and largely remain one-to-one connections between student and equipment. One form of support which is often provided (including in the UTS facilities) is a simple discussion board used separately from the experiment to facilitate student discussion and communication. The student survey described previously [ 20
] included the question: Do you think the UTSOnline discussion board helps in solving your problems while you are using the remote labs? The results gave average agreement values of 6.6 and 4.8 over two semesters, indicating an ambivalent reaction to this mechanism—a conclusion supported by the student comments. This indicates that more effective approaches or tools are required to support enhanced student-student relationships.
In terms of "live" (i.e., during experiment) collaboration, where this does occur it is typically through remote colocation of the students rather than through technological support. If we are to provide support for student-student collaboration where the students are also remote from each other then several issues emerge. The first is the creation of a shared experience which can form the basis for a common learning context. Issues arise such as: how do we provide each student with access to a common view of the experiment? Who has control of the experiment and how can this be managed? How aware of other students (both within their own group and in other parallel groups) can each student be? Where the implementation has used a stand-alone client, this can be a difficult issue to address, though again recent technological developments can assist in addressing this. As an illustrative example, the UTS remote laboratory architecture removed the need for student-side installation of control applications by running the control application in a virtual server which is accessed through a remote desktop. While an elegant solution, this does mean that we are using applications which are not designed for shared access, and the virtual machine on which it runs does not support multiple simultaneous log-ins. A solution currently being developed is to use a separate proxy to access the control application, and this proxy provides shared access (as well as managing who has control) using AJAX techniques to update the users view. Another approach being considered is the integration of real instrumentation into environments such as Second Life ( http://www.secondlife.com
, and see work by IBM in [ 23
]). While this is yet to result in mainstream remote laboratory implementations, it does hint at the possibilities for creating rich shared laboratory experiences.
In terms of student communication (text chat, audio and video connections, and shared workspaces), there has been significant development of technology in these areas, and there are now numerous toolkits which facilitate integration of these functionalities into both web-based and stand-alone applications—including most Learning Management Systems. However, a key issue which should be considered in the design of solutions is the role not only of intentional communication (i.e., where two or more students consciously initiate communication—a focus of most existing development) but also the role of incidental and serendipitous communications. Much of the learning context for students in conventional proximal labs involves incidental interactions with students in their own laboratory groups, as well as other groups in the same laboratory. Being able to "eavesdrop" on related conversations, notice the issues confronting other students, and overhear the questions they are asking the instructor, can all play a role in assisting the learning process. Given this, it is important to consider how emerging internet technologies can be used to support exposing this broader context to students. Partly, this is a design issue—being able to construct interfaces which expose peripheral activities, but it is also a technological issue—in terms of how this rich set of information can be structured and presented to users without it being distracting. Certainly, virtual reality worlds such as Second Life can be used to provide a rich context and their feasibility is improving as the understanding of linking real-time data into these environments develops.
4.3 Supporting the Student-Instructor Relationship
A similar issue to the above is the relationship between students and instructors. To a large extent the utilization of technology will be the same as for student-student interactions, with the difference largely being in the system design, and control over the level of information which can be accessed. Typically, we would want to support both student-initiated interactions ("Please, I need some assistance with...") and instructor-initiated interactions ("You seem to be having trouble with X—can I suggest that..."). This latter form of interaction implies that we need to provide rich information to the instructor so that they can identify when students might be struggling with a laboratory exercise. Some of this might be supported by allowing warning flags to be established (e.g., has the amount of time taken to perform a certain experimental stage exceeded some threshold; has some control parameter been set outside some acceptable range), but it might also be effective to provide alerts based on overall level of, or imbalances in, student-student communication, semantic analysis of any text chats, or other forms of rich data mining.
4.4 Future Trends
Most of the above discussion has focused on what is currently feasible in terms of constructing laboratories which are accessed across the internet. There are a number of trends in the development of internet technologies which are likely to play a role in the ongoing evolution of remote laboratories. While crystal-ball gazing can be fraught with danger, we will nevertheless briefly discuss possible impacts of these trends, arguably from a reasonably conservative viewpoint.
Improved bandwidth availability. As available network bandwidth increases, it will become progressively more feasible for students interacting with remote laboratories to have higher fidelity and resolution audio and video, and a richer collection of media streams. This will pertain not only to the experiment, but to interactions with other students and instructors, and will hence facilitate improved quality of both interaction and contextualization of the experiment.
Improved sensors and actuators.
As the quality of sensors and actuators improves, and costs drops, the extent to which students can understand aspects of the experimental environment, and control that environment will increase. Consider, for example, the beam deflection experiment shown in Fig. 1
. In the current implementation of this experiment, the camera positions, orientations and zoom levels are fixed, as are the locations of the actuators which are used to place a load on the beam. The experiment would (possibly) be enhanced if the students were able to move, rotate, and zoom the cameras, and change the position of the actuator.
Improvements in interaction technology. While AJAX technologies have provided an improved ability to create highly interactive environments, it is expected that future developments in this area will extend these capabilities. For example, AJAX is inherently based on client-initiated events, which proves to be a significant limitation with remote laboratories, where much of the event stream originates on an experiment server. Emerging technologies and architectures which provide server-side content push (or HTTP streaming), such as Comet, can address this limitation and improve the quality of the data presented to the student. Similarly, changes to HTML (particularly the introduction of HTML5) are likely to facilitate richer interfaces—particularly in terms of inherent support for rich media.
Linking real-world equipment. Possibly the most substantial impact on remote laboratories will come not from specific internet technologies, but rather from the way the internet is used. It is becoming increasingly straightforward to connect real world devices into the internet, both in terms of specific equipment and appliances, but also at a finer level of granularity through network-enabled sensors and actuators. While these devices are often installed to support specific applications, they provide a rich data source and control mechanisms that link the real and virtual worlds. This in turn can potentially be used to support much richer experiment experiences. While (real physical) laboratories have often been used because they provide a controlled environment, equally they have also been used because they simplify the logistics of providing access to "real environments" by students. In many cases, it would be more desirable for students to be exposed to real-world environments, and this is only not achieved because of the logistical difficulties. The combination of the internet and networked sensors and actuators can change this. Consider, as a simple example, a thermodynamics laboratory where students monitor the changing temperature profile of a heated steel block, and compare their measurements to those predicted by heat conduction theory. Compare this to an online experiment where students have direct access to live temperature measurements on steel castings in a foundry (which could potentially be anywhere in the world). Apart from being a more realistic context, it reduces the need to establish specific laboratories in those cases where a student-controlled environment is not essential. In essence, these technologies (networked sensors and actuators, and distributed access via the internet) provide an opportunity to move at least some experimentation out of the laboratory and into the real world.
One final aspect that is important to mention is the development of open and standardized remote laboratory architectures and platforms. A key driver behind the development of remote laboratories is the intention to share the laboratories across geographic and institutional boundaries. Effective sharing requires (or is at least greatly supported by) common platforms. While the development of laboratories to date has been characterized by a great diversity of approaches, there are signs that there is now a movement toward the development of common approaches.
When used appropriately, remote laboratories can provide significant benefits over some proximal laboratories. For these benefits to be realized, consideration must be given to the complex interplay between desired educational outcomes, pedagogical design, and the nature of the technology supporting the laboratory. In this paper, we have discussed current technological and architectural issues with remote laboratories, how these relate to the factors which affect student learning, and how these laboratories may evolve in light of future technology developments.
Support for this publication has been provided by The Australian Learning and Teaching Council, Ltd. (ALTC), an initiative of the Australian Government Department of Education, Employment and Workplace Relations. The views expressed in this publication do not necessarily reflect the views of the ALTC.
• D. Lowe and S. Murray are with the Centre for Real-Time Information Networks, University of Technology, Sydney, PO Box 123, Broadway, NSW 2007, Australia.
E-mail: firstname.lastname@example.org, email@example.com.
• E. Lindsay is with the Department of Mechanical Engineering, Curtin University of Technology, GPO Box U1987, Perth, WA 6845, Australia. E-mail: E.Lindsay@curtin.edu.au.
• D. Liu is with the University of Technology, Sydney, PO Box 123, Broadway, NSW 2007, Australia. E-mail: Dikai.Liu@uts.edu.au.
Manuscript received 19 Mar. 2009; revised 18 June 2009; accepted 3 Aug. 2009; published online 13 Aug. 2009.
For information on obtaining reprints of this article, please send e-mail to: firstname.lastname@example.org, and reference IEEECS Log Number TLTSI-2009-03-0038.
Digital Object Identifier no. 10.1109/TLT.2009.33.