So far, we have presented what are cyber-physical labs and how they are used when embedded in an online learning platform. The process of developing and deploying cyber-physical labs before they can be utilized as presented, is composed of different stages . How each of these stages is designed and implemented affects how a CPL can be used and reused, which eventually influences the adoption of CPLs in digital education. In this section, we describe our adopted approach for building and integrating cyber-physical labs in online learning environments as modular, portable and context-aware Open Educational Resources (OER).
1.5.1 Background
UNESCO defines Open Educational Resources as being “any type of educational materials that are in the public domain or introduced with an open license. The nature of these open materials means that anyone can legally and freely copy, use, adapt and re-share them. OERs range from textbooks to curricula, syllabi, lecture notes, assignments, tests, projects, audio, video and animation.” [74]. Teachers can abundantly find online various electronic OERs such as documents, interactive web applications, videos, cyber-physical labs and others from different sources (Google, online educational repositories such as Golabz9, OER Commons10and others).
Teachers gather and structure relevant resources to carry out a learning activity such as a lesson in a MOOC, or an ILS as it detailed in Section 1.2.1, and then share the curated content with students.
As opposed to how presented so far, in some cases an online lab experiment is conducted separately from pedagogical contexts (lessons), and web-based learning environments are not prepared to fully integrate CPLs. For CPLs to be fully integrated in a platform, we claim that they should be able to: (i) retrieve information regarding the context (where they are embedded), (ii) provide action logging, and (iii) save and retrieve data.
Existing cyber-physical lab solutions are in the form of standalone applications or web applica- tions. A basic solution for integration in learning environments is wrapping the CPL web app in an HTML iFrame. This poses a number of challenges to attain the integration goal. In this section, we define the requirements for the design and implementation of educational cyber-physical labs regardless of the target embedding platform. The proposed formalization of the integration layers for CPLs as Open Educational Labs (OEL) is part of the standardization efforts expanded in the IEEE Networked Smart Learning Objects for Online Laboratories Working Group (NSLOL WG), for the P1876 Standard for Networked Smart Learning Objects for Online Laboratories11.
9http://www.golabz.eu/ 10https://www.oercommons.org/
11https://standards.ieee.org/email/2012_09_cfp_P1876wg_web.html
1.5. CPLs as Modular Open Educational Resources
1.5.2 Formalizing the Integration of CPLs in Educational Web-Based Platforms
Our proposed architecture is based on the concept of separation of concerns, where the system is composed of interconnected yet independent components (the modules or layers), which communicate through defined interfaces. To this end, our architecture is three-layer, is depicted in Figure 1.14 and detailed hereafter.
In thefirst layer, the physical equipment of the CPL is abstracted as a set of software services, based on the Lab as a Service (LaaS) paradigm [70, 73]. LaaS is a term derived from the XaaS series of terms, where “X” means everything and “aaS” refers to “as a Service” [43]. Following this paradigm, the assumption is that everything “X” is offered as a service over the internet rather than at a physical space. It is a notion derived from Service Oriented Computing (SOC), where software is made available as a set of services, and hence hiding the dynamics and only exposing the program through a well-described API (Application Programming Interface) [22]. “LaaS” refers to Laboratory as a Service, where a laboratory is abstracted and made remotely available through the internet as a software service. Building a cyber-physical lab according to the LaaS paradigm should result in well-defined APIs to access the lab’s apparatus from a user application. This enables the independence between the two tiers of the traditional Client-Server architecture adopted for cyber-physical labs, where typically the Server side is composed of the lab apparatus and the interfacing software, and the Client side is the user application through which interaction with the CPL is possible. This separation of the Client and the Server enables the personalization of the user web app (the Client), which in our architecture is sitting in Layer 2 of Figure 1.14. The API provides a set of routines to read and write data from and to the cyber-physical lab respectively. The basic implementation should accept requests for data retrieval from the sensors reflecting the state of the lab, and writing data requests on actuators for controlling the lab. The lab as a service is a self-contained layer that is operational regardless of the web app or the hosting platform. Next, in thesecond layer, the cyber-physical lab is ready to be personalized as an Open Educational Lab (OEL). At this layer, the web app should provide the users with an interface to interact with the lab’s apparatus and conduct their experiments. Requests such as actuator control and sensor reading should be implemented by invoking the API calls of the LaaS to gain access to it. At this stage, the cyber-physical lab can be exploited without any context (i.e. without being part of a lesson). But if chosen to be used in a pedagogical scenario, connecting the web app to the LaaS, and augmenting it with user identity management, activity tracking, and experimental data management turns it into an OEL ready to be integrated in a hosting platform (layer 3).
1.5.3 Open Educational Labs
Cyber-physical labs are interactive educational resources, where user-action has an effect on the system, and which generates data belonging to two categories: interaction data resulting from the use of the web app, and experimental data which are the data sent to the actuators and received from the sensors of the CPL. Collecting the generated data and linking it to the originating user is
Chapter 1. Introduction
Figure 1.14 – Formalization of the integration layers for cyber-physical labs in online learning platforms as modular OERs.
important for a number of goals: the generated data from the interaction with the web app UI (User Interface) components (buttons and sliders for example) of the web app is valuable for studying interaction patterns for example, and experimental data are needed by the learners to check their results and possibly use them in other tools as discussed in Section 1.3.1. In order to support the full integration of CPLs in target platforms, there is a need to specify the requirements and accordingly develop CPLs as OELs. Hence, we define Open Educational Labs as being Open Educational Resources which are augmented withaccess management, activity tracking, and data storage functionalities which guarantee a full integration of the CPLs in a hosting platform. Below we detail these three requirements:
Access management: in this thesis, we are interested in the case where a CPL is part of a complete educational activity (i.e. a lesson). We assume that learners connect to the learning activity through an online learning platform, hence having a user identity for authentication with the platform (unless an anonymous mode is used for example). Referring to Figure 1.14, we consider that the CPL will be integrated in the platform through an interfacing module, which in most cases is a third-party application. To prevent the creation of multiple identities belonging to the same user, it is necessary to propagate the user identity from the platform, to the OEL as in Single-Sign On (SSO) for instance. More specifically, when learners are conducting their educational activity, they should have a unique identity that persists throughout the different sessions and the integration layers. This guarantees the consistency of reflecting the contexts, saving activity traces, and collecting experimental data. In our proposal, a user authenticates with the platform to get access to the OEL, the OEL authenticates with the LaaS to get access to lab.
1.5. CPLs as Modular Open Educational Resources User activity tracking: when a CPL is first abstracted as a LaaS, then as an OEL to be integrated in a learning platform, we see that there are several sources of activity traces. At the platform level, the log in and log out times indicate how much time a learner spent in the lesson for example. At the LaaS level, keeping records of the different exchanged requests and responses with the web app can help in bringing meaningful insight into lab usage. Precisely, the experimental parameters can be used to extract usage patterns for a certain experiment and hence understand how students are using the lab when studying a certain concept.
Data storage and retrieval mechanisms: when conducting an experiment, students generate the results of applying parameters on the process of the given lab which they would use for graph- ing or tabulating results for example. To improve user experience as discussed in Section 1.3.1, it is necessary to specify mechanisms for data saving and retrieval.
1.5.4 Proof-of-concept Implementation
In this section, we present the example of the Mach-Zehnder interferometer CPL (detailed later in Section 1.6.1), developed and integrated in Graasp as an OEL according to the proposed guidelines.
The LaaS Layer (Layer 1)
Figure 1.15 depicts the first layer of the Mach-Zehnder as an OEL. The lab equipment is interfaced through a myRIO12to allow software access to it. The services which allow the web client to
control the lab’s apparatus are implemented as APIs on the same board.
The OEL Layer (Layer 2)
In the second layer, the web app provides a web app for students to use the Mach-Zehnder interferometer. The web app has figure-based components for the interaction with the equipment. By clicking on the UI elements of the web app, the users will be altering the state of the lab and experimenting. For example, the photodiode is abstracted as a rectangular box which students can click to turn ON and OFF. The cameras are abstracted as camera-shaped icons, when students click them they are activated, a green halo appears around the corresponding icon and the live feed is transmitted. The web app connects to Layer 1 through the APIs served by the myRIO board.
12The myRIO board is a reconfigurable I/O embedded computer board which supports signal acquisition and generation and network access.
Chapter 1. Introduction
Figure 1.15 – The 3 layers of integration for the Mach-Zehnder interferometer as an OEL.
The Integration in Graasp (Layer 3)
To implement the three requirements for integration: access management, activity tracking and saving and retrieving data, we make use of the OpenSocial container in Graasp (Section 1.2.1) . Because this example lab is integrated in an ILS, we also make use if the ILS library13which,
using the OpenSocial API takes care of ILS specific mechanisms such as identifying in which phase of the inquiry learning sequence the web app is embedded through a one-liner. In layer 3 of Figure 1.15, the integration of the OEL in Graasp within a learning activity in the ILS is shown. In addition to communicating with the LaaS layer, the web app is aware of the user identity through Graasp’s People API and saves associated activity tracks through the ActivityStreams API and experimental data through the Documents API.
13https://github.com/go-lab/ils