Content uploaded by Raivo Sell
Author content
All content in this area was uploaded by Raivo Sell
Content may be subject to copyright.
Lab Description Language - A framework approach
for describing and mediating remote and virtual labs
S. Seiler
1
,
R. Sell
2
, D. Ptasik
3
1,3
Bochum University of Applied Sciences, Bochum, Germany
1
Tallinn University of Technology, Ehitajate tee 5, Tallinn, Estonia
Abstract- More and more universities and schools across the
world are developing different types of remote labs for their own
operations. However, there is very little evidence at the present
time that such local labs are used by or shared with other
institutions in order to provide educational support for a wider
range of students on a regular basis. Several other virtual and
remote laboratories have been developed for a variety of
disciplines. But these diverse proprietary interfaces, software
components and implementations for each experiment are a
problem for learners and teachers (no common user interfaces
and APIs are used). Therefore, it is hard to integrate new remote
labs or create virtual labs for non-engineers. Due to incompatible
software implementations it is also a challenging task to integrate
external labs into an existing lab platform. That complicates the
sharing of labs between different organisations and universities.
With the approach of “Lab Description Language” (LDL) authors
of this paper are introducing a new framework concept for
describing and mediating remote and virtual labs. This concept is
demonstrated using the example of the Virtual Micro Controller
Unit (VMCU) developed by paper authors.
I. INTRODUCTION
In order to solve the problem of providing practical skills to
students due to the lack of equipment and funds in educational
institutions, technology enhanced learning based on the sharing
of equipment between institutions is suggested for wide-scale
implementation across European countries [1,2]. Advances in
Internet-based technologies allow institutions, SMEs and
private individuals to access equipment of other organisations.
However, the main problem today is that there are no standards
or recommendations regarding the requirements for such
equipment (electrical signals, communicational protocols and
compatibility of software). There are merely some suggestions
presented in [3,4,2], but no DIN, ISO, or IEEE standard.
Changing the view to subparts and subsystems, there are
existing different (semantic) descriptions for various science
areas, like sensor descriptions. For instance Compton et al.
analysed 12 different sensor ontologies in 2009, presented in
[5]. While some of them (like Avancha [6] and CESN [7]) are
merely about description of sensors, other like OntoSensor [8]
are also capable of descriping 'components', or like OOSTethys
'processes' in addition. Their conclusion draws the statment,
that a "combination of OntoSensor and the CSIRO ontology
represents the current limit of expressive capability for
semantic sensors", but none of them is able to deal with the
whole context of sensor descriptions [5].
For user interfaces it is almost same situation. Various
descriptive approaches are existing and discussed in the
Model-Based User Interfaces Incubator Group at W3C. These
approaches can be separated into industrial (Collage, Flex,
Open Laszlo and XAML for instance) and research driven
(CAMELEON Reference Framework, MARIA and UsiXML
for instance) ones (compare to [9]).
Another point about the description of equipment being used
for industrial purposes is that this equipment is not necessarily
convenient to be used in the educational process. Moreover,
the ergonomics of industrial equipment are often very different
from the ergonomics required for the equipment to be used in
educational organisations ([10]). This means that it is not a
straightforward process to implement remote controlled
equipment in the educational environment.
Universities across the world are developing different types
of remote labs for their own interests, as presented in [1], [11]
and [12]. However, there is very little evidence at the present
time that such local labs are used by other institutions in order
to provide educational support for a wider range of students on
a regular basis. The common web browser is widely used to
access remote and virtual laboratories [13,14]. Authors in [15]
have introduced the concept of "experiment as a service" and
developed a service-based software infrastructure for remote
laboratories, called DCL (Distributed Control Lab). Examples
of integrated experiments available on DCL are "Higher
Striker" (a real-time control experiment), a programmable logic
controller, and embedded real-time control applications. This
work has been undertaken under the Vet-Trend project [16]
with the main objective to build an open infrastructure for
conducting robotics and real-time control experiments from the
Web. Unfortunately, this concept has not become widespread
so far since there is no established standard and the software
components used in DCL are not publicly available.Authors in
[17], under a project called VISIR (Virtual Systems in Reality),
developed software to allow users in various universities and
other organisations to set up online lab workbenches for
electrical experiments. The software is used by two universities
and students can perform simultaneous experiments on online
workbenches. Several other virtual and remote laboratories
have been developed for a variety of disciplines [18, 19, 20]
However, the diverse proprietary interfaces, software
components and implementations for each experiment are a
problem for learners and teachers (no common user interfaces
and APIs are used). Therefore, it is hard to integrate new
remote labs or create virtual labs. Due to incompatible software
implementations it is a hard task to integrate external labs into
Fig 1. Technical vision using LDL for mediating hard- and
software
an existing lab platform. That complicates the sharing of labs
between different organisations and universities.
Another major problem that slows down the evolution and
distribution of distance labs is that very few qualified staff
members are capable of providing lab equipment on the
Internet, not to mention that it is even more complicated to
completely virtualise given hardware components. A strong
indicator for this is that most of the labs distributed are
engineering related; teachers from other disciplines who lack
an affinity to programming are less likely to provide their labs
on the internet since they lack the technical knowledge and
support to do so. To deal with this issue, the goals of iLabs
project at Massachusetts Institute of Technology in USA, were
to develop a suite of software tools that facilitates online
complex laboratory experiments, i.e., "minimize development
and management effort for users and providers of remote labs,
provide a common set of services and development tools, scale
to large numbers of users worldwide, allow multiple
universities with diverse network infrastructures to share
access". Authors in [21] have compared three web services
based architectures of remote laboratories, DIBE ISILab
(Internet Shared Instrumentation Laboratory), HPI DCL
(Distributed Control Laboratory) and MIT iLab, according to
user interactions and interoperability between remote labs. All
of these architectures collect in a web service interface all the
functionalities exposed by the lab, and use work sessions to
structure measurements and store data sent or received from
the instruments. They stated also that "structuring remote
laboratory functions as a set of services has the major
advantage of allowing the sharing of the physical experimental
setup, while leaving the possibility of customising the client
application interface". From the interoperability perspective,
the authors have tested and proved the possibility of sharing
remote experiments between different institutions, like thesis
authors did in the frame of their own lab development. Most of
the existing Labs are tailored lab-specific experiments and use
diverse proprietary interfaces and implementations, but there is
no common user interface and no common APIs, nor a
common description about them. Despite that, many labs share
similar requirements; new experiments require new
developments, logic, connectors and user interfaces. In other
words, technologies used in current labs mainly lack
reusability and interoperability, for instance they are not
generic enough to be reused in designing and integrating new
Labs. Also, most lecturers do not have wider experience in
interfacing with existing labs, mainly developing client user
interfaces.
The application of distance and remote labs is becoming a
major topic among the scientific community. In the latest call
the European Union provided funding’s for several large scale
projects within the frame of distance and remote lab
application and implantation.
As shown in this chapter, virtual and distance labs are
already in use by various educational institutions. There is a lot
of work to do in this area, yet. Scientific sound evaluation of
learning outcomes as well as long term studies are required to
prove the effectiveness of these approaches. The proper
integration of distance labs into the daily teachings would also
require distinct cooperation’s between educational institutions
since sharing of expensive lab equipment is a key criteria for
the added value of the distance lab concept.
II. CONCEPT
OF LDL
Currently, as stated in the section before, there is very little
evidence for significant sharing of distance lab hardware
between different institutions. The lack of common standards
in lab definition and connectivity specifications is a major
impediment to the adoption and wide-scale networking of labs
for teaching and training purposes.
Educational facilities have their own technological
approaches, so sharing is very complicated since external
software components and data sources cannot be integrated
into existing platforms without major expense. The
requirements in technical knowhow, programming skills and
time are too high for most teaching staff.
Furthermore, there are no common documentation sets,
software platforms or reusable libraries to reduce the workload
for a remote and virtual lab provider. The complexity of the
common approaches delays the evolution of distance lab
approaches and hinders a thematically wider range of potential
lab providers and users from participating in distance lab
networks. As a result of this problem, there is an urgent need
for unification in this field. Therefore, authors goal is to solve
this situation by providing an early draft for descriptive lab
integration (LDL). Figure 1 is introducing the overall concept,
including LaaS provider and LaaS Toolkit Based on the section
before it seems nonsensical to provide a roughly new
description language, without taking existing approaches into
Fig2. - LDL and protocols
account. Therefore LDL is integrating existing best-known
solutions and is enabled to be extended by linking to other
concepts.
A. Technical concept
Lab Description Language (LDL) allows transparent access
to laboratories independent of the type of the system, because
LDL allows labs/experiments to be defined in an abstract
manner, as presented in fig.2. As a long-term goal LDL will be
proposed to the international community (in frame of a
possibly funded IP project) as a potential prototype universal
standard for specification and connection of remote and virtual
labs and associated components. The consideration for
adoption of such a draft idea by engineers, technologists and
scientists will aid the longer-term success of the networked
labs and encourage participations.
LDL provides the ontological basis to develop a web-based
platform incorporating a comprehensive toolbox of
components, component-interfaces and access interfaces. The
standardisation of required interfaces and the development and
free distribution of software components for lab integration and
distribution solves the major problems described in state of the
art. LDL will allow transparent access to laboratories
independent of the type of the system. LDL allows
labs/experiments to be defined in an abstract manner, all
objects needed to integrate existing Labs (button, editor,
widget, interface to software tools, e.g., Matlab), which can
represent different laboratory components, will be
implemented via LDL in terms of tags and attributes based on
OWL2 [22].
B. Lab Ontology
LDL provides the ontological basis to develop a web-based
platform incorporating a comprehensive toolbox of
components, component-interfaces and access interfaces. The
standardisation of required interfaces and the development and
free distribution of software components for lab integration and
distribution solves the major problems of Internet accessible
labs. LDL will allow transparent access to laboratories
independent of the type of the system. LDL allows
labs/experiments to be defined in an abstract manner, all
objects needed to integrate existing Labs (button, editor,
widget, interface to software tools, e.g., Matlab), which can
represent different laboratory components, will be written in
LDL in terms of tags and attributes based on OWL2.
For instance a description of the green LED looks like the
example given in fig 3 and fig 4.
LDL in its current state can be utilized to describe the
interconnection of micro controller based devices, their
interfacing to remote lab platforms, such as DistanceLab. In
addition LDL offers a comprehensive way to describe and
mediate the interfaces of external labs to be included into a
DistanceLab environment, as presented in the source code in
fig 4.
The lack of a common standard is also responsible for poor
participation in distance lab projects. The requirements in
technical knowhow, programming skills and time are too high
for most teachers and university staff. Furthermore, there are
no common documentations, software platforms or reusable
library's to reduce the workload for a distance lab provider.
That is the main reason for low participation rates and also the
reason most lab providers are from software engineering
related fields. The complexity of the common approaches
delays the evolution of distance lab approaches and hinders a
thematically wider range of potential lab providers and users
from participating in distance lab networks.
That's the reason why author proposes the standardisation of
all distance/virtual lab communication interfaces:
1. Standardised description language for lab equipment
2. Standardised communication between lab hardware and
the lab PC
3. Standardised communication between the lab PC and
the server (plug-and-play of labs)
4. A unified method to easily integrate Labs into every
web platform (laboratory as a service concept)
These web platforms can be any learning management
system like Moodle or Blackboard, or it could be the
homepage of a university of even of a private web site.
Integration of labs will be possible on every web platform that
reaches certain technological requirements. As an example:
one should be able to integrate a distance lab on a website as
easily as integrating a YouTube video there (and this is very
easy).
All objects needed to integrate existing Labs (hardware
connectors, bus systems, streams, buttons, editor, widget,
interface to software tools, e.g., Matlab), which can represent
Fig 3. - Description of virtual port connection in LDL
different laboratory components, can be defined in LDL in
terms of tags and attributes in form of an ontology formulated
in OWL2. General idea was to develop an integrated
description which covers all aspects of distance lab integration.
The approach unifies processes among all parties working with
distance labs, the provider, the teacher and the learner. Finally
in last stage the four interface descriptions create a plug and
play distance lab network which is open in all directions.
Teaching staff is able to integrate all available distance labs
into every web site or LMS.
Interface standards that are created are the following: a) real
and virtual lab communication, b) UI description interface, c) a
provider protocol, dealing with:
• real and virtual lab communication, about hardware and
virtual components (cameras, sensors etc.), interfaces
and interaction with the labs
• An abstract GUI description interface - Every lab needs
at least one user interface; most likely there will be more
than one feasible user interface for each lab. Depending
on the experimentation done in a specific lab, different
instruments are required. For example, a simple
embedded programming lab, dependent on the task the
learner is given may require various hardware to
accomplish his task, like an oscilloscope, on chip
debugging or many other kinds of measurement. This is
a huge challenge for the user interface description. A
sound method has to be found to connect the real/virtual
hardware to the compatible GUI components. The
second important topic on this interface is to find a
standard that regulates the integration of LaaS labs in
third party web platforms (like Blackboard, Moodle or
proprietary solutions built by a single university).
• Lab provider protocol, for registering the labs on a
provider system, allowing and controlling access to the
labs. The master server is an instance which controls
and enables communication between the single
components of the system, like learning platforms and
lab providers.
In the scope of this research the general outline for LDL was
set. Ideas and suggestions for a possible widespread
implementation can be found in the next section.
III. F
URTHER DEVELOPMENT AND FUTURE OUTLOOK
Currently, a holistic soft- and hardware toolbox including
documentation for automated plug and play distribution of
remote labs is built upon the general LDL idea, mediating the
ontology formulation to real interaction and labs beyond the
draft implementation in this thesis.
This envisaged toolbox will be easy to operate so that a
provider of distance labs will no longer need programming or
advanced technical skills. Hardware integrations as well as
provision of ergonomic user interfaces should be handled by
this toolbox. All lab related devices (labs themselves,
intelligent tools, UI, LMS) can use LDL to communicate, as
LDL is about the description and the protocol implementation
of the overall system communication. This is delivered by a
web service approach named Laboratory as a Service that is
realised by components/software being developed to use LDL
for communication, the universal approach for lab description
and integration.
LDL has the potential to streamline the creation of new labs
and make many more labs available to the educational
community engaged in the project. The meta-language is
designed and built using existing standards for the semantic
web to encompass all known requirements, but ensuring it can
evolve over time with technological developments.
To implement the early LDL draft into productive real lab
environment, the following tasks have to be undertaken:
1. Technical analysis of common components, detailed
analysis of hardware communication protocols and
standards, formulation of a set of requirements for
generalisation of analysed elements.
2. Analysis of existing labs as well as labs provided by
external providers. Identification of common components,
common approaches in integration and estimation
requirements to a standard given by those identified
elements.
3. Resolving the hardware into generic components like:
sensors, actors, video streaming devices, audio streaming
devices. Components identified need to be exhaustive to
<simulationdevice type="LED"
classfile="virtualmicroclab.simdev.led.LED">
<parameters>
<parameter name="color" type="String" value="green" />
<parameter name="connection information" type="String"
value="add your device description here." />
</parameters>
<resources>
<resource name="activePicture" type="image"
path="components/electrical/LED/Green" />
<resource name="inactivePicture" type="image"
path=" components/electrical/LED/Transparent />
</resources>
<inputpins>
<pin name="Pin0" id="0" />
</inputpins>
</simulationdevice>
Fig 4.
– Simulation Device Description in LDL
cover the entire lab hardware with generic components.
Also, strategies have to be developed for components that
can't be covered.
4. Parameter and Hardware description of generic
components, by formulating hardware descriptions into
LDL ontology and distinguishing reasonable parameter
sets to ensure the hardware components can be configured
for every possible scenario.
5. A Real-time communication protocol requirement analysis
needs to be implemented, following the requirement
definition for a communication protocol that can be used
to control the hardware in a distance lab that is beyond the
state of the draft LDL.
6. Generalisation of standard GUI components (Source code
editor, Video Stream viewer, Input devices (buttons,
regulators, switches)
7. Also, metadata for a booking system must be
implemented.
8. Furthermore, the access to distance labs via mobile
devices such as smartphones and tablets can be supported
as well since the LDL approach is device independent as
well as independent from any operating system or specific
server infrastructure.
A
CKNOWLEDGEMENT
This research was supported by the Estonian Scientific
Foundation grant ETF7542 and EU Leonardo Da Vinci
Programme VAPVoS and Netlab projects.
R
EFERENCES
[1] Gravier, C. et al, State of the art about remote laboratories paradigms
foundation of ongoing mutations. Online-Journals.org, 2008.
[2] A. C. Ammari and J. Ben Hadj Slama. The development of a remote
laboratory for internet based engineering education. Journal of
Asynchronous, Learning Networks, 2006.
[3] B. Balamuralithara and P.C. Woods. Virtual laboratories in
engineeringeducation: The simulation lab and remote lab. Computer
Applications in Engineering Education, 17:108–118, 2007.
[4] Nergiz Ercil Cagiltay, Elif Aydin, Rusen Oktem, Ali Kara, Marian
Alexandru, and Bodo Reiner. Requirements for remote rf laboratory
applications: An educators perspective. IEEE TRANSACTIONS ON
EDUCATION, 52, 2009.
[5] Michael Compton, Cory Henson, Laurent Lefort, Holger Neuhaus, and
Amit Sheth. A survey of the semantic specication of sensors. In Kerry
Taylor, editor, Proceedings of the 8th International Semantic Web
Conference (ISWC 2009), 2nd International Workshop on Semantic
Sensor Networks, 2009.
[6] Sasikanth Avancha, Chintan Patel, and Anupam Joshi. Ontology-driven
adaptive sensor networks. In MobiQuitous’04, pages 194–202, 2004.
[7] Coastal Environmental Sensing Networks. Cesn ontology.
http://www.cesn.org/resources/cesn.owl, 2011. Online, accessed 25.
March 2012.
[8] D.J. Russomanno, C. Kothari, and O. Thomas. Building a sensor
ontology: A practical approach leveraging iso and ogc models. In The
2005, International Conference on Artificial Intelligence, pages 637–643
[9] José Manuel Cantera Fonseca, Juan M. González Calleros, Gerrit
Meixner, Fabio Paternò, Jaroslav Pullmann, Dave Raggett, Daniel
Schwabe, and Jean Vanderdonckt. Model-Based UI XG Final Report.
http://www.w3.org/2005/Incubator/model-based-ui/XGR-mbui-
20100504/.
[10] B. Pradarelli, L. Latorre, M.-L. Flottes, Y. Bertrand, and P. Nouet.
Remote labs for industrial ic testing. IEEE Transactions on Learning
Technologies, 2:304 – 311, 2009.
[11] R.B. Jr. Sepe, M. Chamberland, and N. Short. Web-based virtual
engineering laboratory (ve-lab) for a hybrid electric vehicle
starter/alternator. Industry Applications Conference, 1999. Thirty-Fourth
IAS Annual Meeting. Conference Record of the 1999 IEEE, 4:2642 –
2648, 1999.
[12] Aly I. El-Osery, John Burge, Antony Saba, Mo Jamshidi, Madjid Fathi,
Mohammad-R., and Akbarzadeh-T. V-lab® - a virtual laboratory for
autonomous agents - sla based controllers. IEEE Transactions on
Systems, Man and Cybernetics, 32:791–803, 2002.
[13] Vikram Padman and Nasir Memon. Design of a virtual laboratory for
information assurance education and research. In Proceedings of the 2002
IEEE Workshop on Information Assurance and Securit, 2002.
[14] Teodor Jové Lluís Fàbrega, Jordi Massaguer and David Mérida. A virtual
network laboratory for learning ip networking. In ITiCSE ’02 roceedings
of the 7th annual conference on Innovation and technology in computer
science education, volume 34. ACM SIGCSE Bulletin, 2002.
[15] Frank Feinbube Peter Troger, Andreas Rasch and Robert Wierschke. Soa
meets robots - a service-based software infrastructure for remote
aboratories. Proceedings of the 2nd International Workshop on e-learning
and Virtual and Remote laboratories, 2008.
[16] Andreas Rasche, Frank Feinbube, Peter Tröger, Bernhard Rabe, and
Andreas Polze. Predictable interactive control of experiments in a
service-based remote laboratory. In Proceedings of the 1st ACM
International Conference on Pervasive Technologies, 2008.
[17] Ingvar Gustavsson, Johan Zackrisson, Kristian Nilsson, Javier Garcia-
Zubia, Lars Håkansson, Ingvar Claesson, and Thomas Lagö. A flexible
electronics laboratory with local and remote workbenches in a grid.
International Journal of Online Engineering (iJOE), 4, 2008.
[18] Domenico Ponta, Anna Marina Scapolla, and Paolo Buschiazzo. Survey
of remote laboratories using service oriented architectures. iJOE, 5, 2009.
[19] Paolo Buschiazzo, Davide Leoncini, Rodolfo Zunino, and Anna Marina
Scapolla. A web-based laboratory for digital signal processing.
iJOE,6(S1):6–11, 2010. [20] A. C. Ammari and J. Ben Hadj
Slama. The development of a remote
[21] F. Davoli, F. G. Spano, S. Vignola, and S. Zappatore. Labnet: Towards
remote laboratories with unified access. In IEEE Transactions on
Instrumentation and Measurement, volume 5, pages 1551–1558, 2006.
[22] http://www.w3.org/TR/owl-featur
