A Smart Layer for Remote Laboratories

A SMART LAYER FOR REMOTE LABORATORIES A SMART LAYER FOR REMOTE LABORATORIES Ricardo J. Costa 1, Gustavo R. Alves1 and Domingos S. Santos2 1 LABORIS / Polytechnic Institute of Porto - School of Engineering (ISEP), Porto, Portugal 2 Polytechnic Institute of Porto - School of Engineering (ISEP), Porto, Portugal Abstract - Commonly, when a weblab is developed to support remote experiments in sciences and engineering courses, a particular hardware/software architecture is implemented. However, the existence of several technological solutions to implement those architectures difficults the emergence of a standard, both at hardware and software levels. While particular solutions are adopted assuming that only qualified people may implement a weblab, the control of the physical space and the power consumption are often forgotten. Since controlling these two previous aspects may increase the quality of the weblab hosting the remote experiments, this paper proposes the use of a new layer implemented by a domotic system bus with several devices (e.g. lights, power sockets, temperature sensors, and others) able to be controlled through the Internet. We also provide a brief proof-of-concept in the form of a weblab equipped with a simple domotic system usually implemented in smart houses. The added value to the remote experiment hosted at the weblab is also identified in terms of power savings and environment conditions. Index Terms—Remote Experimentation, Weblab, Domotic System, KNX. I. INTRODUCTION Weblabs are used for educational purposes since the mid 90’s. According to Aktan et al. [1], it was maybe in 1996 the first time an undergraduate weblab has been made fully accessible using networking tools. This solution contributed to the appearance of the Remote Experimentation concept, defined as a distance learning area that enables the remote control of real experiments using computers connected to the Internet. This remote access to labs, commonly used to support the practical work required in sciences and engineering courses, brought several advantages to education, like: a) users (teachers and students) may access resources not available locally, providing the accomplishment of experiments without any costs; b) experiments may be shared among institutions; c) equipment may be used more often; d) costs per student may be reduced; among others [2]. Due to all those advantages, already described in literature, nowadays there is a growing number of weblabs. Since those same labs require specific resources to enable a remote access, several solutions for harmonizing the software and hardware used for implementing them have already been proposed and described. However, the existence of many different technologies difficults the choice for a standard approach to implement a specific weblab both in terms of hardware and software. Usually, when a specific weblab is required, an immediate and particular technical solution is adopted for this development. Moreover, due to the specificity of each solution, usually only qualified people are able to develop one, which partially justifies that almost all weblabs fall into the engineering domain [3]. Thus, harmonization at hardware and software levels is an important aspect to take into consideration as to facilitate the construction of standard and well defined weblabs. If harmonization is followed, software/hardware modules used in each weblab may be reused on others. This will ease the creation of weblabs and promote its widespread use in the teaching and learning domain. Moreover, by following a standard architecture, other aspects may be considered during a weblab implementation, namely the environment of the physical space occupied by it and the power infrastructure. By controlling these two common aspects to all weblabs, further control facilities are given to remote users. They will be able to control the place where a specific experiment is running, like if they were in the place, contributing to approach the in-place lab facilities to weblabs. To implement these aspects in any weblab, we propose the adoption of a standard domotic system bus usually implemented in smart houses, which will ease the control of all the environment aspects encountered in any lab. The rest of this paper is organized as follows: in the next section we discuss those same weblab requirements, namely issues concerning the control of the physical space (light incidence and temperature) and the power sockets where the lab devices are connected to; section 3 presents the use of a domotic system bus within a client-server architecture; and section 4 describes the solution adopted for our lab that enables remotely controlling two specific devices (a halogen lamp and a power socket). The paper ends with some considerations about the work already done and future directions. II. ANALYSIS OF REQUIREMENTS Each weblab requires a specific place to accommodate the apparatus, the measurement equipment and the servers. Usually, those places have characteristic light incidence, temperature and humidity conditions, containing all the equipment power supplied. Figure 1 illustrates a possible place to host a remote experiment, surrounded by several equipment also able to control remotely. The necessity to adopt a weblab to support the practical work, 24 hours per day, 7 days per week, has consequences in the power consumption and in the results obtained from the experiments. Specific attention should be paid to the physical environment where an experiment is running, namely with the light and temperature conditions. Supposing that a weblab facility has direct sun light and visual feedback is required, then artificial lights are not mandatory, i.e. they are not required to be switched on during the day. iJOE International Journal of Online Engineering - www.i-joe.org 1 A SMART LAYER FOR REMOTE LABORATORIES Figure 1. Physical space associated to a weblab. Eventually, controlling the blinds can provide better light conditions depending on the part of the day and of the present season. During the night and when not in use, the lights at the weblab may also be switched off in order to save energy. Besides, depending on the type of prototype and equipment used in the remote experiment, the ability to control/monitor the temperature may be required. For that purpose, two solutions may be considered: the temperature control can be made automatically within the weblab, or users may be provided with the ability to control it remotely. In the first solution, an air-conditioning system, inside the weblab, controls the temperature and continuously guarantees that prespecified conditions are satisfied for a correct lab operation. Alternatively, the temperature can be monitored by a sensor and, based on the readings, users may change it for a specific value, by remotely controlling fans, heaters or even specifying a new temperature value for the air-conditioning system. Although not being a common request in a remote experiment, same weblabs may require a precise temperature control. This is the case with experiments that use specific materials that change their properties according to temperature. Another situation, where temperature control may be required, is in some environments where the measurement devices require a given temperature in order to work properly. In both situations, remote users should have specific information about the equipment, so as to adjust the present temperature conditions to the required ones. An additional requirement that should be considered is the ability to switch off each device of the weblab, when not in use. If possible of being done remotely, the all lab may be switched off when a specific experiment ends. Latter, when another experiment is starting, the remote user may turn it on. This will contribute to a reduction of the power consumption and hence of the energy costs. Additionally, it may also be desirable to reinitialize a certain device by applying an off/on sequence. These suggestions/requirements depend on whether the device and apparatus to be switched off/on requires a setup procedure or not. Considering a PC, for instance, it is not possible to switch it off by just pulling out the plug from the power socket, i.e. by simply switching it off. If in some devices turning off the power will take them into a default state, on others we have to follow a specific sequence for that purpose. This is usually the case with the apparatus, which sometimes requires a software initialization made by an Instrumentation Server. In this situation, if we intend to setup the entire weblab by resetting it, first we have to reset the Instrumentation Server and then the apparatus, so it can be reinitialized by using control signals coming from the Instrumentation Server. Again, specific attention is required in the way the Instrumentation Server is reset, since it can not be turned off abruptly because it could damage the software installed on it. Preferably, the server should be reset by an UPS (Uninterrupted Power Supply) using a soft reset that allows turning off the server by software. If all these setup and reinitialization considerations are supported through remote control, then the technical support, usually made by a technician, may be reduced or even suppressed, which also contributes to reduce the weblab maintenance costs. Moreover, switching off all devices and the apparatus, when not in use, reduces the ageing effects, which also contributes to the quality of the results obtained from the remote experiments. To address all the previous points, we propose using a specific architecture with a standard domotic system bus, usually implemented in smart houses. The advantage of using a standard solution is that all institutions currently supporting weblabs may quickly adopt it with small development efforts. III. PROPOSED ARCHITECTURE Commonly, weblabs are idealized for specific experiments. Several literature have been proposing architectures regarding the control of weblabs. However, from our knowledge, few have considered the ability to remotely control the physical space as well as the power sockets where the lab devices connect to. At this point two situations are common: 1) this requirement is not even considered; 2) in-house specific solutions are used to tackle the problem. To address both situations we propose weblab designers to considerate the possibility of using a standard domotic system bus, in the way illustrated in figure 2. This proposed architecture contains two servers: the Instrumentation Server and the Web Server, both connected through an Intranet. All devices available in the weblab, namely the experiment apparatus, Webcams, and the measurement equipment are controlled by the Instrumentation Server. In order to facilitate the development of a weblab, all devices have to be autonomous, i.e. they should be able to work in an independent way, which means that all the hard processing tasks should be made inside each one. The Instrumentation Server only sends/receives basic signals to control and monitor each device. At the same time, the Instrumentation Server transfers information to/from the Web Server enabling the interface between remote users and the lab. Another relevant aspect presented in the proposed architecture is the UPS. This unit is connected to the Instrumentation Server via a serial RS232 connection, and to a power socket controlled by the domotic system bus. By turning off this power socket, the UPS will send a signal to the Instrumentation Server, instructing him to initiate a software shut down sequence. This avoids the application under execution in the Instrumentation Server, from being damaged because of a sudden power failure (i.e. an off command) or an improper shut down sequence. iJOE International Journal of Online Engineering - www.i-joe.org 2 A SMART LAYER FOR REMOTE LABORATORIES Figure 2. Suggested architecture to control the temperature and light conditions plus the power infrastructure (power sockets) of the weblab physical space. Users must establish a Web connection to the Web Server so they can download the web interfaces designed for a specific device (PC, PDA, Smart Phone or Mobile phone), to control the weblab. The Web Server should also contain the relevant pedagogical contents, as weblabs experiments are mainly used for transferring knowledge and for practicing theoretical concepts [3]. This means that a database is required together with a Virtual Learning Environment both intending to keep e-learning course contents (e.g. documents and images) together with specific tools for course management, like assessment tools and others. Moreover, since usually only one experiment is available in a specific weblab, the Web Server should also have an access management system, required to handle simultaneous accesses [4]. Additionally, the Web Server should also control the domotic system bus. For this purpose, it must be coupled to the domotic system bus so that a software layer installed in it may enable remotely controlling all lab devices. This facility should be made by the Web Server because it is the only device required to be permanently turned on, to allow the weblab availability 7 days per week, 24 hours per day. Thus, by adopting this architecture it is possible to remotely turn on/off the entire weblab and control the physical space. Specific domotic devices named actuators are directly connected to lamps, temperature sensors, and other devices, and are characterized by having a dedicated processor that enables doing specific control tasks required for each of those devices, like: increasing lights intensity, open/close blinds, controlling the temperature and so on. Besides controlling each device, the processor within the actuator has also the ability to understand a communication protocol, specific of the domotic bus. Adopting this solution, the Web Server will be free from the hard processing tasks. This will facilitate the adoption of this architecture for all weblabs, because it is not necessary to develop the hardware, and the software will be much easier to build. Besides, if we adopt a commercial domotic system, which guaranties a well tested solution, user’s confidence to use the weblab will increase. Based on the presented architecture, we have implemented a solution at our lab which specifically enables remotely controlling a halogen lamp and the power supply that powers the experiment apparatus. IV. IMPLEMENTED LAYER The technology used to implement the architecture illustrated in the previous section was the KNX standard domotic system, usually found in smart houses [6]. In the Web Server we installed a software layer to control the KNX system. Instead of implementing the KNX protocol from the scratch, we developed the software layer using a JAVA API named CALIMERO developed by the Vienna University of Technology, Automation Systems Group [5]. This API provides a set of methods to control the KNX bus communications and all the connected devices. The next sub sections present all the development aspects of both hardware and software levels implemented at our lab, together with a brief introduction to the KNX standard domotic system. A. Physical devices and their configuration Detailing on the choice of the KNX system, it is both a European Std. (CENELEC/EN 50090 and CEN/EN 13321-1) and a world Std. (ISO/IEC 14543-3), it is platform independent, guaranties interoperability of products from different manufacturers and stands for high product quality guaranteed by the KNX Association [6]. The KNX/EIB denomination is often used in literature iJOE International Journal of Online Engineering - www.i-joe.org 3 A SMART LAYER FOR REMOTE LABORATORIES because the KNX standard is based in the communication stack of the EIB specification. Besides, it also integrates new configuration mechanisms and communication media originally developed by other domotic specifications, namely Batibus and EHS. Figure 3 presents the set of KNX devices used in our lab that, locally and remotely, allows to: 1) turn on/off and adjust the brightness of a halogen lamp; 2) switch on/off a power socket. Figure 4 contains some photos of those devices. Figure 5. Push button used to locally control the devices connected to the domotic system bus. TABLE I. DOMOTIC DEVICES USED IN THE WEBLAB. Manufacturer Functionality Price (€) (May 07) Tronic dim actuator 1gang 215W built-in (75331002) Berker Controls the brightness of the halogen lamp and allows turning it on/off 310.80 Switch actuator 2gang 10A built-in (75332001) Berker Turns on/off the power socket 271.43 IP/EIB router (AP 146 /5WG1 1463_B01) Siemens Converts IP to EIB frames and interconnects the KNX bus to an Intranet/Internet 769.23 Power supply (5WG1 1221AB01) Siemens Supplies the KNX domotic system bus 314.63 ABB Allows controlling locally the halogen lamp and the power socket 182.00 Device Figure 3. Domotic system implemented in the weblab. Push button (6323 3f-tritonswitch sensor) Figure 4. Pictures of the KNX domotic system used in the weblab. Besides the power supply required for the KNX bus, this topology contains two device types: two actuators (dimming and switching actuators) and a 3 gang push button (control touch sensor). The actuators are directly connected to the elements that will be remotely/locally controlled (the halogen lamp and the power socket) using the push button. By using each button of this sensor, users may locally turn on/off the power socket, and the halogen lamp and control its brightness, as illustrated in figure 5. We connect the KNX bus to the Web Server using an IP/EIB router. This router converts all the IP frames, sent by the Web Server, to EIB frames, to control and monitor each element. Table 1 specifies the actual devices used in our lab, the manufacturer, their functions, and the actual market price (relative to May 2007). Notice that others may be chosen, with the same implemented functionalities and eventually with lower prices. ∑= 1848.09 All the devices available in the domotic system bus were previously configured by a software package named ETS [7]. With this software installed in a common PC with the Windows XP OS, we: a) defined an address for each KNX device so they can be recognized in the bus; b) specified the operation of each device, configuring its parameters (e.g. specified that a simple touch in one button of the sensor will turn on/off the lamp); and c) implemented a logic connection between the devices to allow their communication. After configuring the bus and the devices, we had to download that configuration to the system by connecting, through a local network, the ETS to the KNX bus. This transference required the use of the IP/EIB router using a specific IP and port address. Figure 6 presents a screenshot with the configurations made in the ETS system to program each KNX device iJOE International Journal of Online Engineering - www.i-joe.org 4 A SMART LAYER FOR REMOTE LABORATORIES server is required. With this solution, instead of having two open Web accesses, one to control the domotic system bus and the other to control the experiment, we only need one to control both. All commands received in the Web Server, used to control the experiments, are redirected to the application installed in the Instrumentation Server. The disadvantage of this second solution is the requirement to develop two distinct applications to control the lab. However, we will only need one open Web connection, which promotes higher security. Figure 6. Configuration of the domotic system using the ETS software. B. Remote control There are in the market some IP gateways that allow controlling the KNX system through the Internet. However, all have in common rigid Web interfaces which are not able to change. This means that if we want to build a specific interface, we have to face with several buttons eventually not required for a specific experiment. Besides, using a gateway will be expensive (its price rounds 1000 €). Then, if we use the required Web Server to remotely control the KNX bus, the solution will be cheaper and will facilitate the construction of appropriated Web interfaces for each remote experiment. Thus, we developed a new software layer to control the lamp and the power socket available in the weblab. Besides controlling the KNX system, the architecture is modular and may be used by any experiment, since it works together with any existing weblab. Figure 7 presents the software modules implemented at our lab, where a particular attention should be paid to the Web Server and to the domotic bus connections. The architecture uses two servers with specific software, both following a client-server approach. Since the Instrumentation Server is attached to the weblab apparatus, it should have a software application to control the lab. However, if we want to remotely control the lab, the Instrumentation Server must also have an HTTP (HyperText Transfer Protocol) server installed, so users may download specific Web interfaces. However, an HTTP server is not always required to be installed in the Instrumentation Server. It may have a resident application communicating with another application running in the Web Server. In this situation, all the Web interfaces will be accessed through the Web Server where an HTTP Power Power Supply Supply The presented solution contains the usual steps made when a simple KNX system is configured to be used locally. For the remote control, another software layer was specified to control all KNX devices (as locally done through the push button). Figure 7. Implemented software architecture to control the KNX/EIB devices. We developed a client-server application for the Web Server that enables remotely controlling the KNX domotic system bus. As previously said, this application is required to be in the Web Server because it controls the power socket of the UPS connected to the Instrumentation Server, i.e. if the software application was installed in the Instrumentation Server the user would not be able to turn it on/off neither to reset it. To avoid developing all the logic behind the KNX/EIB protocol, we used the JAVA API Calimero integrated in a JAVA server application (Servlet). However, to use the Calimero API, an IP/EIB router was required to transmit information from the Servlet application to the KNX/EIB bus. All details behind the KNX protocol are hidden in this API together with the router, facilitating development tasks. Besides, we didn’t need to place the router near the Web Server, since all data control generated by the Servlet are transported through an IP network. The only requirement during the development was the use of the specific port 3671 to access the IP/EIB router. In other words, we can not use a firewall that blocks port 3671 between the router and the Web Server, in particular with the Servlet application. Since this application was developed using JAVA software and as it follows a client-server architecture, the Web Server runs an HTTP server named TomCat [8] to understand and process user’s requests together with the Java Servlet Technology [9]. When a specific user wants to access the lab, he/she makes an HTTP access to the Web Server using a particular IP address, and a Java Applet, illustrated in figure 8, will be downloaded to his/her PC. iJOE International Journal of Online Engineering - www.i-joe.org 5 A SMART LAYER FOR REMOTE LABORATORIES Any interface developed to control a specific experiment may work together with this interface that enables users to remotely control the domotic system bus. To use this last interface, an user must establish a connection to the KNX/EIB bus, by pressing the buttons available in bottom-right corner (fig. 8). After connected to the bus, a message notifying the users will appear at the bottom of the interface, indicating a successful connection or any problem that may have occurred. Assuming a successful connection, remote users are able to control the KNX devices (lamp and power socket) using the buttons to turn them on/off and the slide bar to regulate the lamp brightness. Since we adopted the HTTP as the communication protocol between the Servlet application installed in the Web Server and the Java Applet, any change made locally may be actualized in the Applet by making a refresh. This refresh procedure, which may be done by simple reloading the Applet, is made automatically every 30 seconds, updating the interface for user’s monitorization. Turns on/off the lamp Indicates if the action was made remotely Information about actions made in the bus Turns on/off the power socket Server application (JAVA servlet) (2) Open/close the KNX bus connection Figure 8. Web interface (Java Applet) used to control the KNX domotic system bus. All interactions made between users and the Web Server are described in figure 9, illustrating the step sequences from initially connecting to the Web Server until finally controlling the KNX devices: 1. Using a Web browser, users access a Web page located in the Web Server. 2. Within this page, a Web interface (an Applet) is downloaded to the user’s PC. 3. Once the Web interface has been downloaded and opened, users have the ability to control the lamp brightness and the power socket of the weblab by sending commands to the Servlet application. 4. The Servlet sends those commands to the IP/EIB router, in order to control the devices. 5. For a local control, technicians may use the push button that works independently of the server application. (1) (3) Calimero API (4) Intranet / Internet IP / EIB router KNX/EIB (5) Figure 9. Process sequence used to control, locally and remotely, the KNX devices. V. Controls the lamp brightness Light Intensity Status=34% Web Server User CONCLUSIONS AND FUTURE WORK Educational requirements promoted the development of several software tools to support the teaching and learning processes. These tools, within PCs connected to the Internet, facilitated the remote control of equipments promoting the emergence of the Remote Experimentation concept, which allows students/teachers to access real labs in order to run experiments, almost in the same way as they would do locally. This solution brought many benefits to education providing versatility, since anyone may access a real lab at anytime from everywhere, while at the same time reducing the costs in education. However, to provide a weblab it is necessary to implement a hardware/software infrastructure. Usually, these implementations do not follow a standard solution (hardware and software) and the control of the physical space, together with the power sockets, are often forgotten. If these remote control facilities are implemented in a weblab, the energy costs may be reduced (the apparatus are able to be turned off when not in use) and the quality of the experiments may also increase, since all the physical space (light, temperature, and others) may be controlled and monitored. To provide all those facilities in a weblab, this paper proposed the use of a standard domotic system named KNX. By adopting this system, it will be easier to implement a uniform weblab architecture and it will be straightforward to implement additional control facilities to the remote users. Based on all these advantages, this paper presented an implementation of the KNX system bus in a weblab, enabling to control through the Internet a halogen lamp and a power socket using a JAVA Web interface (an Applet) within a Web page accessible through a PC. By developing specific Web interfaces, this same approach may be adapted to other users’ devices, like PDAs, SmartPhones or Mobile Phones, increasing the access versatility, by enabling students/teachers to use recent mobile devices. A log database, keeping all the actions made in the KNX devices, may also be implemented in the future, bringing benefits to the assessments, since it will facilitate teachers to understand some of the actions made by students in the weblab. iJOE International Journal of Online Engineering - www.i-joe.org 6 A SMART LAYER FOR REMOTE LABORATORIES To conclude, we can say that this paper intended to be an alert to the ability of controlling other aspects usually forgotten in Remote Experimentation, namely the physical environment and the power sockets used to supply a weblab. Moreover, adopting a domotic system bus, like the KNX Std., will promote the construction of a uniform architecture using commercial domotic devices. ACKNOWLEDGMENTS This work was only possible with the collaboration of Intelbus Lda. [10] that provided some of the KNX devices used in the presented solution. REFERENCES [1] [2] [3] [4] [5] [6] B. Aktan, C. A. Bohus, L. A. Crowl and M. H. Shor, “Distance Learning Applied to Control Engineering Laboratories,” IEEE Transactions on education, vol.39, nº 3, 1996. G. Alves, J. M. Ferreira, D. Müller, Heinz-H Erbe, N. Hine, J. B. M. Alves, C. Pereira, L. Chiang, O. Herrera and E. Sucar, “Remote Experimentation Network - Yielding an Inter-University Peer-to-Peer e-Service,” 10th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA’05), Catania, Italy, 19 - 22 Sept., 2005. Jing Ma and Jeffrey Nickerson, “Hands-on, Simulated, and Remote Laboratories: A comparative Literature Review,” ACM Computing Surveys, vol. 38, nº 3, 2006. J. M. Ferreira and A. Cardoso, “A Moodle extension to book online labs,” International Journal of Online Engineering (iJOE), vol. 1, nº. 2, 2005. Calimero API – “EIBnet/IP is a client library that supports tunneling connections to the KNX/EIB bus,” available at: http://calimero.sourceforge.net/, 2007. KNX – “Association that promotes the KNX standard for Home and Building Control,” available at: http://www.konnex.org/, 2007. [7] ETS – “Tool Software design to configure intelligent home and building control installations made with the KNX system,” available at: http://www.konnex.org/knx-tools/ets/intro/, 2007. [8] TOMCAT – “Apache Tomcat Web Server,” available at: http://tomcat.apache.org/, 2007. [9] Java Servlet Technology – “Java Servlet technology provides Web developers a consistent mechanism for extending the functionality of a Web server and for accessing existing business systems,” available at: http://java.sun.com/products/servlet/, 2007. [10] Intelbus Lda. – “Company that implements solutions in the domotic area,” available at: http://www.intelbus.pt/, 2007. AUTHORS Ricardo J. Costa is an Assistant Professor at the Department of Electrical Engineering of the Polytechnic Institute of Porto - School of Engineering (ISEP). He is also a member of the LABORIS/ISEP research lab, Rua Dr. Bernardino de Almeida 431, 4200-072, Porto, Portugal (mail:rjc@isep.ipp.pt). Gustavo R. Alves is a Professor at the Department of Electrical Engineering of the Polytechnic Institute of Porto - School of Engineering (ISEP). He is also the responsible for the LABORIS/ISEP research lab, Rua Dr. Bernardino de Almeida 431, 4200-072, Porto, Portugal (mail:gca@isep.ipp.pt). Domingos S. Santos is an Assistant Professor at the Department of Electrical Engineering of the Polytechnic Institute of Porto - School of Engineering (ISEP), Rua Dr. Bernardino de Almeida 431, 4200-072, Porto, Portugal (mail:dss@isep.ipp.pt).´ Manuscript received on June 22, 2007. iJOE International Journal of Online Engineering - www.i-joe.org 7