Standartization Use Case of Solid-State Laser Lab and RF & Microwave Amplifier Remote and Virtual Laboratories at Labicom

This paper outlines a demonstration of a few remote and virtual laboratories at Labicom platform that were built with accordance to main IEEE P1876TM ideas. A few standardization approaches at above mentioned remote and virtual laboratories are briefly discussed. These laboratories were presented at interactive Labicom demo session during REV'16 conference and published in conference proceedings under title “Labicom Labs: Remote and Virtual Solid-State Laser Lab, RF&Microwave Amplifier Remote and Virtual Lab. Interactive demonstration of Labicom labs in winter 2016”.


INTRODUCTION
Remote laboratories field is growing slowly and is still very far from providing enough supply to educational demand.At the same time the Internet technologies matured significantly since the major adoption of new standards such as HTML5.
On one hand, many commercial web-studious build user-friendly interfaces and rich client applications en masse but they are not aware of the academic specifics and their product lifecycles are not compatible with academic projects, therefore they usually cannot meet the requirements of educational institutions.On the other hand, university teams have very good understanding of what they want to build but they don't know how to do it.So, they lack industry expertise and often build their software within students' projects.Quality of such software is of very low level when it comes to scale it beyond the prototype or outside scientific research.
In order to close this gap Labicom [1] creates various software tools and libraries of industrial quality that allow building advanced remote and virtual laboratories.Such laboratories are pluginless thin client applications running in the browser.The code is created with HTML5/CSS3/JavaScript/WebGL which means that an end user does not need to open ports, make changes in network configuration and settings, install any software except for web-browser, etc.These applications are crossbrowser and cross-platform though surveys show that most students use Google Chrome [2].
However, during development process we realized the importance of standardization and unification in software on many layers.During the demo session at REV'16 conference [3] we showcased two remote and virtual laboratories.Software parts for both were built at Labicom, while hardware belongs to corresponding institutions.
All mechanical parts of the optical bench are automated and mechatronic devices are employed.
In current version of RLL students investigate timedomain, energy and spatial characteristics of a solid-state laser in free-running and monopulse modes.The lab session aims to support theoretical lessons but the online lab design also makes stress on the engineering practical part of working with lasers.Graphical user interface mimics real parts of the experimental test bench: oscilloscope, energy meter, resonator controls, beam profiler.Up to this moment students have been using 2D tabbed user interface (fig. 1, 3).In the beginning of the major development efforts at Labicom we wanted to test a few hypotheses.Since both remote and virtual laboratories require substantial parallel software development tracks, it made sense to investigate if these two modes are worth spending equal resources on them.For this end we worked closely with the professors and students at Quantum Electronics and Basics of Laser Technologies courses at BMSTU for a few years.During testing remote and virtual laboratories at BMSTU we came to the conclusion based on the feedback that professors want to provide students with both types of online laboratories and not as a matter of having choice but as a mandatory means to thoroughly prepare for the remote lab session within unlimited learning time.
During 2016 academic year we are also starting to test 3D interface (fig.2).Its preview was also briefly shown during REV'16 demo session.Comparisons of these two interfaces and reports will follow later.

III. MICROWAVE AMPLIFIER LAB DEMO
Microwave Amplifier Remote Laboratory from Keysight Technologies at HSE Moscow Institute of Electronics and Mathematics [6] consists of the RF signal generator, signal analyzer and hi-end oscilloscope (fig.4).
Looking at the user interface solely one might think that this is LXI-controlled instruments brought to the end user by their built-in tools.In reality, unlike LXI or similar technologies, this solution makes it possible to place various instruments on one page, to integrate them into learning management system (LMS), to deliver remote lab outside local network without changing network topology or configuration, to run the remote lab in a modern browser without installing any additional applications or plugins.
Microwave and Radio Frequency (RF) instruments are placed in the corresponding tabs in the user interface.There is also video stream from the web camera on the actual experimental site.Both single and continuous modes of operation are supported for the lab oscilloscope and signal analyzer.All changes of the real instruments are also reflected in the web interface.
In the microwave amplifier laboratory students investigate parameters of the microwave amplifier by feeding it with RF signals from a signal generator and observing response in the time domain with an oscilloscope and in the frequency domain with a signal analyzer that students need to setup and operate correctly.
Both laboratories were built on the same software framework and use the same libraries.Each laboratory also contains real-time video streaming from the laboratory to user browser.This functionality is transparent both for the laboratory developer and an end user.It is running on Labicom infrastructure and available out of the box.
All above mentioned laboratories were available for live demonstrations at REV'16 from all internet-enabled devices.IV.STANDARDIZATION PROCESS Initially standardization at Labicom was limited to configuration data structures that defined object hierarchy inside given laboratory.Each laboratory had its own set of rudimentary internal API documentation.Every laboratory server used LabicomConnect software to send arbitrary datasets and commands between laboratory server and a client.Although it was a big step forward in comparison to creating network layer manually, still every laboratory was unique in terms of software.
Later in 2014 Labicom developed lab server LabVIEW template that allowed significantly accelerating software development on experimental side of the laboratory by providing common application architecture and many code snippets.The first version of Labicom Lab Server Template consisted of master-slave design pattern with dedicated hardware loops controlled by master-slave design pattern [7].It also used hardware abstraction layer which allows easily changing measurement instruments, data acquisition devices and loading virtual models to emulate real devices.Hardware abstraction layer also allowed using variants inside private class data structures (clusters) to pass unknown parameters at run-time.For example, one energy meter at RLL would have normal COM or USB interface controllable by VISA drivers whereas another would have only .NET API.At instantiation phase when application calls particular class both interfaces would be cast to "Variant" datatype and be passed with dataflow as variants.It allows us to change only children classes without making any major changes in the high-level application itself.
Labicom Laboratory Server LabVIEW template was demonstrated by Igor Titov at EXPAT'15 conference [8] during the technical workshop "Something from 'almost' nothing.Developing and deploying LabVIEW-based remote lab server on Labicom platform: steps, tools and skills" (fig.5).During workshop it was shown how to create working laboratory server from the template in thirty minutes.In that case the remote lab was a simple Arduino board with a LED-indicator and a button controllable via web-page.Block diagram (fig.6) of workshop LED laboratory server consists of the same blocks as block diagrams of more complex laboratories.Thus, reusing laboratory server template was first shown to be a feasible approach.W. Halimi, C. Salzmann and D. Gillet have also proposed using laboratory server template [9].
LabicomConnect was integrated into this template.It is currently a LabVIEW plugin consisting of dedicated VI palette with functions like "Initialize", "Start", "Stop", "Send Data" and many others.
Next, after working with EPFL researchers C. Salzmann and D. Gillet [10,11] on Go-Lab D4.1/4.5 [12] showcase it became clear that standardization at Labicom should go beyond internal APIs, templates and data structures.External reconfigurable yet unifiable APIs should be available in different laboratories and different types of laboratories (remote, virtual, hybrid, datasets).We consider Go-Lab D4.1 to be the main breakthrough in standardizing online laboratories at that time.Main drawback for us in this proposal was its focus on relatively simple remote laboratory which did not cover some scenarios that were essential for quite complex laboratories at Labicom.Lately all interested parties were gathered under IEEE P1876™ standardization working group umbrella.Initial draft was largely based on Go-Lab D4.1 but now it is being modified to meet demands of larger set of online labs [13].Latest versions of Labicom laboratories were created with this document and corresponding discussions in mind.For example, while being very different laboratories Remote Laser Laboratory (RLL) and Microwave Amplifier Laboratory now use the same metadata structures, the same dataflow routines, and the same laboratory server architecture.Now we are able to add new learning supporting tools and new interfaces much quicker.
Also we research developing 3D-interfaces for remote laboratories that also use existing standardization techniques.More research and development is needed in 3Dinterfaces and virtual reality applications in remote labs.
Thus, the whole development process streamlined and accelerated as a result of standardization even if it is invisible for the end users.Standardization will be improved on all levels of the software.
A few gamification techniques will be added to all laboratories.
Also we work hard on introducing natural user interfaces in our labs.

VI. CONCLUSIONS
Using various standardization processes during remote and virtual labs development proves to be very helpful not only for connecting external laboratories to the platform but also for unifying the software on client and lab server sides thus significantly cutting needed development resources and costs.
Standardization procedures and IEEE P1876™ working group are starting to bring value into Labicom development.

Figure 1 .
Figure 1.Graphical 2D user interface of the RLL web-client in the web-browser.

Figure 2 .
Figure 2. Graphical 3D user interface of the RLL web-client in the web-browser

Figure 3 .
Figure 3. Students at BMSTU are preparing for remote lab session with the virtual laboratory at Labicom (RLL, 2D user interface) PAPER STANDARTIZATION USE CASE OF SOLID-STATE LASER LAB AND RF&MICROWAVE AMPLIFIER REMOTE AND VIRTUAL..

Figure 4 .
Figure 4. Graphical user interface of the Microwave Amplifier Laboratory (Oscilloscope Tab)

Figure 5 .
Figure 5. Technical workshop.Igor Titov shows how to create laboratory server from Labicom template for Arduino LED used as experimental device in thirty minutes.
PAPER STANDARTIZATION USE CASE OF SOLID-STATE LASER LAB AND RF&MICROWAVE AMPLIFIER REMOTE AND VIRTUAL..

Figure 6 .
Figure 6.LabVIEW block diagram of Arduino LED remote lab created from Labicom lab server template