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