GOLDi – Grid of Online Lab Devices Ilmenau

—Based on a grid concept of an interactive hybrid online laboratory we will describe different fields of applications in different learning scenarios. This infrastructure guaranties a reliable, flexible as well as robust usage of this online lab. By using GOLDi, students are able to design control algorithms with different specification techniques to control electro-mechanical hardware models in the online lab. Additionally, the reconfigurable rapid prototyping platform of the GOLDi system can be used to test all the taught topics of a given lectures in the field of digital system design. Finally, a special demonstration platform (a ball in a labyrinth on a balance plate) can be used to give the students a better feeling about the possibilities and limitations of remote control and observation via Internet and to evaluate these technologies critically.


INTRODUCTION
Our interactive hybrid online lab -called GOLDi (Grid of Online Lab Devices Ilmenau) -stands for a grid concept to realize a universal remote lab infrastructure. This new infrastructure, shown in Figure 1, consists on the server side of three parts [1,2]: • an internal serial remote lab bus, • a bus protection unit (BPU) to interface the selected control unit with the remote lab bus and to protect the remote lab bus from misuse and damaging as well as • a physical system protection unit (PSPU), which protects the physical systems (the electro-mechanical models in the remote lab) against deliberate damage or accidentally wrong control commands and which offers different access and control mechanisms. The interconnection between the web-control units and the selected physical hardware model during a remote lab work session (experiment) as well as the user management is done by the remote lab server, which also handles the webcams.
Our remote lab is used for teaching practical lessons as well as to give hands-on experiences for the development of embedded electronics. This is not done using on-site lessons, but remote via the Internet. This has the advantage that courses can be offered internationally world-wide and gives students from different countries, speaking different languages, the same access and equal possibilities in the lab. Additionally, even for local students the lab offers extended opening hours (twentyfour-seven) when compared to a regular lab. Besides the advantages for students, this also reduces the costs for academic teaching and improves the quality by offering more practical training possibilities.
For a reliable, universal and more flexible usage of our remote lab we installed an internal serial remote lab bus. All web-control units and all the physical hardware models are interconnected via this bus. With this bus concept we are able to add additional web-control units on the one side as well as further physical hardware models on the other side to build an internal remote lab grid, where any combination of physical hardware and control units can be used for experiments [1,3]. The bus protection unit (BPU) receives commands from a control unit and simply checks them for bus validity. This is done by verifying the transport protocol. The content of the transmitted data and addresses are not checked, because this depends on the physical system used and is therefore done by the specific model protection units of the physical systems. The function of the bus protection unit is to prevent a control unit from blocking the bus and causing others to be affected. The bus protection unit is based on the same hardware as the protection units for the physical hardware models in the remote lab but uses a different population of components to simplify production and maintenance. A secondary task for the bus protection unit is to interface various control units like the PLC to the bus. This unit, for example, can only supply simple I/O control which is intended to interface the physical systems directly, therefore no protocol is implemented. The serialization of the I/O signals and the implementation of the protocol are handled by the bus protection unit. The level shifting, in case the control unit is not compliant with the bus voltage, is done by the bus protection unit as well [2,5].
The physical system protection unit (PSPU) is necessary when students execute their algorithms directly on the control unit and want to be free in their choice of design tools. Compared to the approach used so far, there was no possibility to check, if the executed commands are PAPER GOLDI -GRID OF ONLINE LAB DEVICES ILMENAU safe for the physical system. This means, damage could be caused by invalid commands. The task of the protection unit is to check for command safety by filtering all commands. Only commands that will not cause any malfunction are executed. All others are discarded and optionally reported as an error condition to a learning management system (LMS). This concept can be used with all control units like Microcontroller, FPGA, PLC, etc. Using such a universal protection unit gives the students the largest degree of freedom for their design, because no precautions have to be taken into account. Therefore, no additional security framework (workbench) within the software and hardware control design is required to prevent malfunctions of the physical system [4].
The complete design flow is carried out at the students' side, giving them a more authentic look at a real world project design flow. The valid behavior of model protection unit is compared against the commands received from the control unit to determine any unsafe control commands of a faulty student's control algorithm. Commands that are valid for the current state of the physical system are passed. Commands that are not valid and could cause a failure or any other unwanted behavior are discarded and optionally reported. Besides pure web based training for students, controlled by the control units, the PSPU also offers the possibilities to be accessed by the teachers over the Internet for e.g. initialization of experiments or be accessed by local control. It is also possible to mix signal sources e.g. to get certain sensor signals from the model and supply others via a web interface.
This can be used in cases where a user input at the models is required to test the system behavior (e.g. a key press at an elevator). The details of the different modes and possibilities will be described in the paper [4,5].

III. EXPERIEMNT CONTROL PANEL
On client side (student's PC) GOLDi offers a Webbased environment -the experiment control panel (ECP) -supporting the above mentioned features to generate and execute a design by using simulation models. The increasing capacity of wireless communication and the growing number of mobile devices (e.g. smartphones and tablets) on the one hand as well as modern Internet technologies like JavaScript, HTML5 and Web Sockets on the other hand provides new possibilities and challenges in the area of mobile learning. Therefore a realization as HTML5 application was chosen for the Web-interface.
By using the ECP, the student is able to: • upload the synthesized/compiled designs to the corresponding Web-control units in the lab room, • handle the experiment (e.g., start, stop, reset), • use the interactive debugging features (break on sensor/actuator changes or special conditions), • change environmental variables if necessary and • watch the experiment by manipulating environmental variables inside an I/O monitor or by observing the control of the physical system directly via a webcam.

IV. GOLDI LABS CLOUD
Actually the GOLDi infrastructure is used within two running TEMPUS projects: Wider objective of the ICo-op project [6] is e.g. to empower university-enterprises partnerships in Armenia, Georgia, and Ukraine by modernizing engineering education based on remote engineering and virtual instrumentation; enhanced with transversal knowledge and competences at universities and offering contemporary methods of the vocational education and training for adults in enterprises. One of the specific objectives of the DesIRE project [7] is e.g. to create remote and virtual laboratories in the area of Embedded System in Armenia, Georgia, and Ukraine for distance and e-learning.
This means, that each project partner receives a complete remote lab. Totally GOLDi remote labs are running at ten universities in Armenia, Georgia, Germany, and Ukraine. One implementation problem we have had to solve is the maintenance of each partner remote lab: • Any new functionality or a new firmware must be implemented manually on each partner website. • Each institution has specific modifications according their own requirements. • Each university has different network architecture.
• Each university has different remote lab configurations. • To have access to an experiment of the partner labs, a separate user account on the corresponding partner website is necessary.
Each GOLDi partner has to handle the maintenance itself -supported by the Ilmenau GOLDi project team. We realized very quickly that this procedure is very ineffective.
We decided to reengineer the network of all GOLDi remote labs to a GOLDi cloud system [8,9]. Available GOLDi Servers (it means available partner remote labs) are registered in the GOLDi cloud. They are highlighted colored as ready to be used on the central GOLDi website (see Figure 2). The new cloud structure (see Figure 3) has the following advantages: • Maintenance of the whole system on one central location: www.goldi-labs.net • All partner universities have the same GOLDi version. • New functionalities are immediately available for all partners.  Each GOLDi client communicates with the GOLDi cloud for the central user and experiment management and the booking management. All privacy-relevant data of the cloud are located in the computing department of the Ilmenau University of Technology with highest privacyrequirements and will never be exchanged with the local GOLDi Servers of the partner institutions.
With the local GOLDi Server each client exchanges only the sensor/actuator signals during a running lab experiment directly.