Topics in Educational Cyber-Physical Labs:Configurations, Data Collection and Analysis

Recent advances in remote sensing and actuation technologies, coupled with the large reach of the internet, allowed for the emergence of applications such as cyber-physical labs. Cyber-physical labs are the digital and remotely-accessible equivalent of the lab equipment students use in school to experiment, through web-based interfaces such as web applications. Students, teachers and lab owners derive value from these systems, they are our stakeholders. Students are the intended users, teachers are the educational content curators and lab owners are the service providers. In this thesis, we take a close look at issues pertaining to cyber-physical labs and propose new approaches to address them. We also analyze the use of such systems in a MOOC, to detect the impact of the exherted experimental behavior of students on their academic performance. First, we tackle the case of the generation of web apps interfacing cyber-physical labs. It is the equivalent of preparing experiments for teachers by arranging the equipment for multiple experiments with the same equipment. We propose an extension to the Smart Device Specification for cyber-phyiscal labs, and a tool which generates these apps based on it. The automatically generated apps implement the necessary functions to use a cyber-physical lab, and are ready to be integrated in online learning platfroms. Next, we investigate issues related to the collection and retrieval of students' generated data through their interaction with cyber-physical labs. We consider the needs of students and lab owners. Through questionnaires sent to both parties, we elicit the requirements for an activity-tracking infrastructure composed of a vocabulary and an architectural model. The proposed vocabulary ensures deriving value from the recorded activity, and the proposed architecture addresses privacy and data access issues pertaining to students and lab owners respectively. We evaluate our proposal with two example cyber-physical labs. Last, we collect the interaction data with a cyber-physical lab used in a MOOC. We devise computational analyses on the students activity statistics, in search for indicators of academic performance. We find that high and low performing students show statistically different activity statistics. Then, we sequence the steps students did in an experiment, and don't find any statistically significant patterns for low and high-performing students. This analysis provides insights on the usage of installed facilities to service a potential massive access to limited resources (lab installations), and shed light on possible indicators for academic performance

The Smart Wind Turbine

Remote experimentation is at the core of Science Technology Engineering and Mathematics education supported by e-learning. The development and integration of remote labo- ratories in online learning activities is hindered by the inherited supporting infrastructure’s architecture and implementation. In this paper we present a remote experiment (The Smart Wind Tur- bine) built following the Smart Device Paradigm and integrated in an Inquiry Learning Space: the rich open educational resource defined in the EU project Go-Lab. Graasp- an educational social media platform, is the authoring and hosting tool. The Golabz platform is the dissemination medium among teachers and students

Access to Massive Open Online Labs through a MOOC

Few MOOCs offer laboratory work as part of their educational material, yet it is known that hands-on sessions are important components of science and engineering education. Equally important is understanding how students are using labs as part of their learning activity outside the constraints of space and time. In this work we present the initial results of the usage of a remote lab provided as part of a Control Systems MOOC

The Mach-Zehnder Interferometer: A smart remote experiment based on a software template

Hands-on laboratory sessions are one of the pillars of science and engineering education. It is reputed that institu- tions find it difficult to provide enough laboratory setups that cover all taught scientific topics due to logistical and budgetary limitations. With the recent advances in web technologies en- abling real-time interaction, remotely accessing physical devices became possible, and so the rise of remote experimentation as a solution to the mentioned limitations. The development and deployment of remote laboratories is still a tedious process for lab providers, given the need to write new applications for each new lab. In this paper, we propose a software template for lab providers that will alleviate some of their concerns by following the Smart Device Paradigm and Specifications and abiding to software engineering rules to produce a reusable and flexible solution. We will show how this in-progress template can be used for implementing a remote Mach-Zehnder Interferometer

Enabling the Automatic Generation of User Interfaces for Remote Laboratories

Remote laboratories are an important component of blended and dis- tance science and engineering education. By definition, they provide access to a physical lab in a distant location. Many architectures enabling remote laboratory systems exist, the most common of which are Client-Server based. In this con- text, the Server interfaces the physical setup and makes it software-accessible. The Smart Device Specifications revisit a Client-Server architecture, with the main aim of cancelling the dependencies which inherently exist between a Client and a Server. This is done by describing the Server as a set of services, which are exposed as well-defined APIs. If a remote laboratory is built following the Smart Device Specifications, any person with programming skills can create a personalized client application to access the lab. But in practice, teachers rely on the mediated contact with a lab provider to have information about what kind of experiment(s) the lab in question implements. Even though there is a complete description of the available sensors and actuators making up a lab and how to be accessed, it is not clear how they are connected (relationships). In this sense, a list of sensors and actuators are not enough to make a guided selection of compo- nents to create the interface to an experiment. Therefore, the aim of this work is to support teachers in choosing the experiments and creating the respective UI on their own, in a pedagogically oriented scenario and by taking into consideration the target online learning environment. This is done by revisiting the Smart Device Specifications and extending them, in addition to proposing a tool that will automatically generate the user interface of the chosen experiment(s)

Standardization Layers for Remote Laboratories as Services and Open Educational Resources

Deliveringeducationandeducationalresourceshasevolvedfromclass- centered settings towards distributed, cloud-based models. This is mainly the con- sequence of publicly available educational resources such as documents, videos, and web applications. At the same time, emerging technologies in information and communication are enabling the development and deployment of remote lab- oratories on the Web. Today, these freely and openly available educational inter- active media are known as Open Education Resources (OERs). Learning manage- ment systems, MOOC platforms, and educational social media platforms provide a medium for teachers to create their teaching activities around OERs in a struc- tured way. To enjoy an effective and productive learning experience, it is neces- sary for the educational resources to be fully integrated in the hosting platform. While most platforms have a ready-to-embed infrastructure for certain types of OERs, they are not ready to host remote laboratories in an integrated fashion. In this paper, we define the necessary integration layers for remote labs in on- line learning environments. The work is validated by two implementations with different target platforms

Go-Lab Specifications of the Lab Owner and Cloud Services (Final) – M30

This deliverable details the final specifications of the solutions devised for integratingremote labs in the Go-Lab infrastructure. The infrastructure comprisesmany services supporting students and instructors for inquiry learning with onlinelabs. Using the Specifications of Lab Owner and Cloud Services presentedin this document, lab providers should be able to create/adapt and smoothlydeploy their labs in the Go-Lab infrastructure.In this document, a decoupled Client-Server architecture is proposed for remotelaboratories, where the Client is the user application enabling to operate the labat distance and the Server offers services enabling communication through theInternet with the physical lab and its instrumentation. This architecture topologyis based on the Smart Device paradigm presented in later sections of thedeliverable. Relying on this schema, the specifications provide lab owners witha way to build new labs or adapt existing ones in conformity with the Go-Labrequirements. The resulting labs are able to interact with the Go-Lab bookingsystem (see D4.2 of M18, and the final version D4.6 upcoming in M33), thelearning analytics services (see D4.2 of M18, and the final version D4.6 upcomingin M33), and specific applications provided by Go-Lab (for example the DataViewer App which displays data from the sensors of a lab).The core of the deliverable is divided in two main parts: sections 2 & 3 whichrespectively detail the specifications for new and legacy (or existing) labs.For new remote labs, the required services, protocols, and data formats forcommunication between the Client and the Server are presented, together withguidelines for internal functionalities. The Smart Device paradigm on whichrelies the Client-Server architecture conceptualizes and embeds the lab-ownerservices.Compared to the initial version D4.1(R2), the main changes in this deliverableaffecting the Smart Device specifications deal with the modification of the metadata,and adding more recommendations for lab providers developing labs forGo-Lab.In section 2.3.3, a new field is added to the metadata describing a sensor:the type field. This modification is meant to make sensor representation moredescriptive. Additionally, lab owners are advised to require an authToken evenfor observers when they are accessing labs. This modification was the result ofmany use cases discussed with members of the Go-Lab project. Additionally,a compact version1 of the specifications was accepted and presented at theREV20152 conference.For existing labs, the Smart Gateway paradigm is proposed, which aims at makinglegacy labs compatible with the Go-Lab requirements. Due to the largetechnological variety of legacy remote labs, the Smart Gateway approach offersdifferent compatibility levels through its different adaptation mechanisms. TheSmart Gateway paradigm conceptualizes and embeds the cloud services.A double goal of this deliverable is to maximize the number of remote labs availablefor teachers by federating external laboratories as well as to maximize theperformance of the usage of these laboratories. This leads to an importanttrade-off: the more labs supported, the smaller is the subset of common featuresor requirements which can be imposed on them to be integrated with therest of the ecosystem. This is the reason for providing two complementary approaches(Smart Device and Smart Gateway). The Smart Device paradigm isimplemented by any new laboratory and requires particular formats and technologiesthat guarantee a high integration with the rest of the project. The SmartGateway provides different tools to integrate existing labs in Go-Lab, with differentlevels of integration. These labs are called legacy labs in this deliverable toemphasize that this is applied to external existing laboratories rather than to newlaboratories that should use as much as possible the Smart Device paradigm.In regards to the Cloud Services section, the main addition compared to the initialversion D4.1(R2) is the support of a new logging mechanism for user actions(Section 3.6). Essentially, the Smart Gateway previously provided two levels ofintegration: a full integration and a low level integration. The full integration issupported by a protocol translator, which requires significant development efforts:the remote lab developer would re-implement the user interfaces and protocols.For the low level of integration, a simple Smart Gateway plug-in needsto be developed, and the lab provider only needs to secure the connection betweenthe user and the laboratory. The second integration level was found moreattractive for lab owners, since it is more convenient in time constraints. However,its main drawback is its lack of support for integration with the rest of theGo-Lab ecosystem. For example, it is not possible to benefit from the LearningAnalytics features developed in other tasks of the project. In this final version ofthe specifications, we introduce a lightweight approach to support the user actionlogging feature without requiring to support the rest of the protocol translatoror the Smart Device paradigm.The final release of the Go-Lab specifications as provided in this deliverable isused as a draft standardization document for the IEEE P1876 Working Groupon Networked Smart Learning Objects for Online Laboratories and will be discussedin the upcoming meeting, which will be held at the Exp.at’15 Conferenceon June 1st, 2015

Go-Lab Releases of the Lab Owner and Cloud Services (Final) – M33

This deliverable is the corresponding companion of D4.5 Specifications of theLab Owner and Cloud Services. The latter deliverable has been submitted atM30, and is the final document detailing the solution devised by Go-Lab for integratingnew and legacy remote laboratories (labs) in its infrastructure. Go-Labprovides two approaches to integrate remote laboratories: the Smart Deviceand the Smart Gateway approaches. While the first corresponds to the developmentand deployment of new labs, the second is destined for existing labs. Yet,both implement the Smart Device Paradigm as presented in D4.5, and brieflypresented in the Introduction of this document. Starting from the specificationspresented in D4.5, lab owners are expected to be able to create/adapt andsmoothly deploy their labs in the Go-Lab platform.In this deliverable we provide templates for lab owners to use in order to interfacetheir new physical labs with embedded devices (the Smart Devices). Thetemplates provide the architecture skeleton for the laboratory server applicationfollowing the Smart Device paradigm. The templates implement a set ofspecifications to ensure that they are scalable, readable, and maintainable; insuringthe ease and augmented use of these templates. Using the templates,lab providers are not concerned about the architecture of their lab servers. Thistask is alleviated by the templates. The targeted platforms are Node.js on BeagleBoneBlack (BBB), and LabVIEW on myRIO . We also provide example labsimplemented with the produced packages, as well as with other platforms andtechnologies.We also provide support for existing online laboratory systems with the SmartGateway. The Smart Gateway supports both real laboratories (e.g. Remlabnet)and simulation (e.g. Concord, QuVis). The integration of these labs in theGo-Lab infrastructure with the Smart Gateway means that all current and futurelaboratories provided by these systems are and will be automatically availablefor Go-Lab consumption. Each of these systems offers more than 20 laboratoriesat the moment, which is a good gain for the project. Additionally, newdeveloped features of the Smart Gateway since D4.3 are presented, such as thesupport of internationalization of external laboratories, and new mechanisms forthe integration of laboratories (HTTP plug-in examples)

The Smart Device Specification for Remote Labs

This paper presents the Smart Device specification to interface with remote labs. To encourage the broader sharing of remote labs, the Smart Device paradigm decouples the client from the server and provides well-defined interfaces between client and server. Such Smart Device services are exposed on the Internet and enable interoperability with client applications, other Smart Devices and external services (e.g. a booking service). This paper presents the extensible and platform-agnostic specification of the Smart Device services and internal functionalities. The Smart Device specification contains sufficient service metadata to enable the automatic generation of basic client applications. The specification is illustrated through an example and first implementations of the specification are presented

Rich open educational resources for personal and inquiry learning: Agile creation, sharing and reuse in educational social media platforms

International audienc