Elsevier

Computer Standards & Interfaces

Volume 43, January 2016, Pages 21-29
Computer Standards & Interfaces

Interoperating remote laboratory management systems (RLMSs) for more efficient sharing of laboratory resources

https://doi.org/10.1016/j.csi.2015.07.004Get rights and content

Highlights

  • We address the benefits of remote laboratories and Remote Laboratory Management Systems (RLMSs).

  • We shed light on a major obstacle in RLMSs development.

  • We address this issue and propose a novel Application Programming Interface (API) design pattern.

  • We explain the capabilities of the proposed pattern using an illustrative case study scenario.

  • We adopt the proposed standard to create an API for inter-communicating the two common RLMSs SAHARA and ISA.

Abstract

In this paper we propose a novel Application Programming Interface (API) design pattern for inter-communication between Remote Laboratory Management Systems (RLMSs) accommodating different levels of functional support and thereby allowing more efficient sharing of laboratory resources regardless of their hosting RLMS. Afterwards, we present initial results and demonstrate the feasibility and effectiveness of this pattern by developing an API for two common RLMSs, Sahara and the iLab shared Architecture (ISA). As a result, users logging into a Sahara server managed to access and manipulate a radio-activity experiment hosted on an ISA server.

Introduction

Laboratories are generally recognized as important tools for education and scientific research. The challenges in resourcing conventional laboratories [1] and the rapid evolution of computer technology and communication networks have supported the emergence of remote laboratories as a viable educational tool [2], [3]. As a result, remote laboratories have strongly been adopted in many engineering disciplines, especially those oriented to control and industrial real world, such as industrial informatics [4], [5], [6], [7] and industrial electronics [8], [9]. Remote laboratories have become increasingly sophisticated, with a growing body of research considering aspects such as flexibility of access [10], ability to share resources and labs [11], [12], security of users, data, and devices [13], and accessibility for disadvantaged users [14] among many others [15]. To a significant extent, many of these issues have been successfully overcome, with continuous, reliable and high quality services being maintained for much of the past decade.

Cross-institutional laboratory sharing is one of the most often raised justifications for the use of remote labs [11], [16]. This can lead to improved utilization levels, shared costs, and access to a much broader range of laboratory apparatus. Thus, the focus of remote laboratory development is now moving towards more sustainable models that promote both institutional and individual engagement [16]. Rather than individual academics custom building equipment for their specialized subjects, remote laboratory development is increasingly being carried out by multi-institution consortia [16]. Despite its claimed benefits, the related initiatives have been historically very limited and struggled to achieve sustainability. Early examples of attempts to support shared access RLMSs include the World Wide Student Laboratory [17] and PEARL [18] projects. Similarly, the LearNet [19], ProLearn [14] and PEMCWebLab [20] projects were carried out during the early to mid-2000s with little success. More recently the LiLa [21], Sahara [11], [16], [22], [23], ISA [24], [25], [26], Weblab-Deusto [27], [28], NANSLO (Western Interstate Commission for Higher Education 2012) and UniSchooLabS [29] projects have continued to attempt to support laboratory sharing.

A key element of these developments is the creation of Remote Laboratory Management Systems (RLMSs) that provide a common online framework for accessing and administrating a wide pool of heterogeneous developed remote lab systems that might be distributed across different institutions and geographical locations [13]. They provide services such as booking, assessment, tracking, and synchronous and asynchronous communication tools, as shown in Fig. 1.

RLMSs should be agnostic with regard to the remote laboratory design in order to support the widest range possible of remote laboratories. Examples of RLMSs that are specifically designed to directly manage a collection of remote laboratories include iLab Shared Architecture (ISA) [24], [25], [26], and Sahara [11], [16], [22], [23]. Other systems have some related functionality but have a different focus. For example, LiLa [12] provides some laboratory services (such as location and booking services) but not others (such as monitoring the laboratory status), though it does extend into wider support for the experimental activities. Each of the different RLMSs has typically arisen from a different set of pedagogic and technical design parameters, and philosophical approaches. Each has different strengths and weaknesses, and potentially addresses a different set of needs. We argue that this diversity is an asset that should be encouraged rather than avoided. However the diversity does represent a challenge with regard to supporting cross-institutional sharing of laboratories between institutions using different RLMSs.

Currently, for a remote laboratory that is provided by one institution to be accessed by users from a different institution, typically those users must directly access either the laboratory itself or the providers RLMS (if one exists). This can represent a significant hurdle to effective sharing given that it potentially places a substantial burden on the provider of the laboratory to coordinate access for the users. It can also mean that students who access multiple laboratories (possibly shared from multiple providers) will need to manage numerous access accounts and system interfaces.

Common issues facing RLMS could be summarized as follows:

  • Inability to achieve Inter-institutional sharing and interoperability with heterogeneous RLMSs in order to share learning objects (ex., courses, remote labs, etc.) among institution.

  • Lack of a standard design pattern, which increases the developing time for attaching the same remote laboratory to different RLMSs at different institutions.

  • Inability to access labs from different systems within a single interface as well as duplicated maintenance efforts for accounts on multiple systems.

This can be partially addressed by an architecture that uses federation and single sign-on technologies so that a student from institution A can access the RLMS from institution B through a mechanism defined by the federation and contracts between institution A and B. The downside of this is that the students must still access different remote laboratories through different systems. A common portal might address this to some extent, but the system would then potentially lack a consistent look-and-feel. An alternative, which we focus on in this paper, is to allow the home institution of the students to maintain their own RLMS, and for this system to be able to interoperate with other RLMSs so that students can directly access provider's experiments. In other words, consider the scenario shown in Fig. 2, where the RLMS ISA is installed at the Massachusetts Institute of Technology (MIT) and providing access for the MIT users (MIT 1, MIT 2…) to experiments installed at MIT (MIT Exp A, MIT Exp B…). On the other hand, the RLMS Sahara is installed at the University of Technology, Sydney (UTS), providing access for the UTS users (UTS 1, UTS 2…) to experiments installed at UTS (UTS Exp A, UTS Exp B …). Adopting an Application Programming Interface (API) to communicate between both systems, it would be possible for a UTS user to gain access through Sahara to experiments installed at MIT and integrated in ISA if there is an agreement between both institutions and as long as both architectures support this API in order to interconnect with each other. Since API is meant to be language independent, any RLMS provider could implement them even if the RLMS architecture was not initially considering its provision in its designed. For instance, it could be provided as a plug-in. It is also necessary to mention that the API approach provides a solution for a higher level communication among RLMSs, and once the communication is established and access to a particular remote lab is granted, communication will be dictated by the lab itself.

In this paper we address this limitation and describe a novel API design pattern for inter-communication between RLMSs defining the underlying design principles, the supported profiles and the set of calls underlying each profile, as shown in Section 2. In the same section, we explain the capabilities of the proposed design using a sequence of illustrative scenarios. Afterwards, in Section 3, and basing on the proposed design pattern, we develop and implement an API to allow a radio-activity experiment hosted on the ISA server at the University of Queensland to be accessed by users logging into a Sahara server at the UTS. Finally, the conclusion and the future works are addressed in Section 4.

Section snippets

Design pattern

The proposed pattern was developed by the faculty of Engineering and IT at UTS with the aid of several partners from the Global Online Laboratory Consortium (GOLC) [30], which encompasses pioneers in remote laboratory development from all over the world. In this section the pattern is defined and discussed. However, it is anticipated that as the builders of RLMSs gain experience with this pattern further refinements will be required. The pattern was realized from a wide perspective in order to

Application

Sahara and ISA are considered to be leading extant RLMSs, owing to their successfully implementation and deployment across many universities [23], [24], [31]. Sahara and ISA offer similar functionalities but their architectures are significantly different [16], [32]. ISA offers a relative comparative advantage in batched labs and its distributed architecture, whereas Sahara offers advantages for interactive labs, queuing, and seamless integration of new experiments. There are some elements

Conclusion and future works

In this paper a novel API design pattern was proposed in order to address the current lack of communication and interoperability between different RLMSs, which is considered one of the major challenges in the future development and deployment of remote laboratories. Initial results derived from implementing this pattern in the API development were successfully achieved, where a user logging into Sahara server could access a batch radio-activity experiment hosted at an ISA server. These results

Acknowledgments

The authors would like to acknowledge the support of the following projects: e-Madrid (S2013/ICE-2715), RIPLECS (517836-LLP-1-2011-1-ES-ERASMUS-ESMO), MUREE (530332-TEMPUS-1- 2012-1-JO-TEMPUS-JPCR) and Go-Lab (FP7-ICT-2011- 8/317601). As well, authors would like to acknowledge the support of the Spanish Ministry for Economy and Competitivity for the granted internship for Mr. Tawfik at UTS within the project s-Labs (TIN2008-06083-C03-01).

References (33)

  • A. Hofstein et al.

    The laboratory in science education: foundations for the twenty-first century

    Sci. Educ.

    (2004)
  • J.E. Corter et al.

    Constructing reality: a study of remote, hands-on, and simulated laboratories

    ACM Trans. Computer-Human Interact. (TOCHI)

    (2007)
  • M. Tawfik et al.

    Common multidisciplinary prototypes of remote laboratories in the educational curricula of electrical & computer engineering

  • M. Garcia Valls et al.

    Usage of DDS data-centric middleware for remote monitoring and control laboratories

    IEEE Trans. Ind. Inf.

    (2013)
  • P. Gaj et al.

    Computer communication within industrial distributed environment—a survey

    IEEE Trans. Ind. Inf.

    (2013)
  • I. Santana et al.

    Remote laboratories for education and research purposes in automatic control systems

    IEEE Trans. Ind. Inf.

    (2013)
  • H. Hassan et al.

    Smartphone-based industrial informatics projects and laboratories

    IEEE Trans. Ind. Inf.

    (2013)
  • A. Yazidi et al.

    A Web-based remote laboratory for monitoring and diagnosis of AC electrical machines

    IEEE Trans. Ind. Electron.

    (2011)
  • A. Melonyan et al.

    Facilitating remote laboratory deployments using a relay gateway server architecture

    IEEE Trans. Ind. Electron.

    (2013)
  • C. Bright et al.

    Factors that impact learning outcomes in Remote Laboratories

  • D. Lowe et al.

    Labshare: towards cross- institutional laboratory sharing

  • T. Richter et al.

    LiLa: a European project on networked experiments

  • C. Gravier et al.

    State of the art about remote laboratories paradigms—foundations of ongoing mutations

    Int. J. Online Eng. (iJOE)

    (2008)
  • L. Gomes et al.

    Current trends in remote laboratories

    IEEE Trans. Ind. Electron.

    (December 2009)
  • M. Tawfik et al.

    On the design of remote laboratories

  • D. Lowe et al.

    Evolving remote laboratory architectures to leverage emerging internet technologies

    IEEE Trans. Learn. Technol.

    (2009)
  • Cited by (0)

    View full text