Remote Experiment Development Using an Improved ... - LearnTechLib

Download PDF
17 downloads 18851 Views 702KB Size Report
Comment
Abstract: In this paper, we present an improved unified framework for ... is becoming increasingly more stable and suitable for cross-platform system design. ... IO is a software package of Node.js which is implemented on the server side, and a ...
Remote Experiment Development Using an Improved Unified Framework Ning Wang Department of Electrical and Computer Engineering University of Houston United States [email protected] Xuemin Chen Department of Engineering Technology Texas Southern University United States [email protected] Gangbing Song Department of Mechanical Engineering University of Houston United States [email protected] Hamid Parsaei Department of Mechanical Engineering Texas A&M University at Qatar Qatar [email protected] Abstract: In this paper, we present an improved unified framework for facilitating remote experiment development. This improved unified framework includes two innovative solutions, namely, real-time remote experiment live streaming video transmission and real-time control command and experiment data transmission. With the new framework, users can conduct or view the real-time remote experiment with most of Internet browsers without the firewall issues and without the need for a third party plug-in. In addition, this new unified framework will significantly benefit future remote laboratory development.

Introduction Remote experiments are defined as that users conduct real experiments using real instruments and components through the Internet. Remote experiments have played more important role in E-Learning for easier sharing, more flexible and less maintenance cost. The remote laboratory can make number of experiments available for students through an alternative solution, which allows students to perform real experiments remotely via the Internet (Boehringer, Jeschke and Richter, 2009). Remote experiments offer a range of benefits that can significantly improve pedagogical success: 1) they adapt to the pace of each student; 2) an experiment may be concluded from home if the time allotted at the laboratory was not sufficient; 3) it can be repeated to clarify indeterminate measurements obtained at the laboratory; 4) the student may improve the effectiveness of his or her time spent at the laboratory by rehearsing the experiment beforehand; 5) safety and security are improved as there is no risk of catastrophic failures (Ferreira, Sousa, Nafalski, Machotka and Nedic, 2009). In the last two decades, the researchers have carried out numerous initiatives to develop and implement remote laboratory activities especially for engineering education. This trend resulted concomitantly from the availability of innovative software packages for instrumentation and simulation, as well as the necessity to better support active and collaborative learning. In these solutions for the remote laboratory development, there are mainly two kinds of system architecture, i.e., Client-Server architecture and Browser-Server architecture. In the early remote laboratory system, most of solutions for remote experimentation mainly relied on Client-Server architecture (Gillet, Salzmann, Longchamp and Bonvin, 1997). Examples include the three-tank system virtual and remote control lab with remote panel which was provided by the National Instrument’s LabVIEW (Laboratory Virtual Instrument Engineering Workbench) (Duro, Dormido, Vargas, Dormido-Canto, et al,

-2003-

E-Learn 2014 - New Orleans, LA, United States, October 27-30, 2014 2008), a digital-signal-processor-based remote control laboratory at University of Maribor (Hercog, Gergic, Uran and Jezernik, 2007), the Distance Internet-Based Embedded System Experimental Laboratory (DIESEL) at the University of Ulster (Callaghan, Harkin, McGinnity and Maguire, 2006) and others. Later on, ClientServer architecture based on Web services and .NET remote services were developed and deployed for remote laboratories (Callaghan, Harkin, McColgan, McGinnity and Maguire, 2007). With the continuing improvements to computer performance, the technology supporting the BrowserServer architecture is becoming increasingly more stable and suitable for cross-platform system design. The new technologies have since been developed to support more complex Internet applications based on a web browser. To adopt the Browser-Server architecture, LabVIEW integrated a new feature to interact with the Virtual Instruments by using the RESTful web services technology. REST (REpresentational State Transfer) provides a lightweight protocol accessible to a wide variety of clients. This architecture does not require complex message passing and provides a simple interface for the user to use Web services in LabVIEW. However, it requires installing the LabVIEW runtime engine on the client side to view and control the virtual instruments (Olmi, Cao, Chen and Song, 2011). In addition, as the number of remote experiments increases, the software is not capable of handling multiple users with multiple resources. Consequently, a unified framework for remote laboratory experiments development in order to allow the setup of a distributed network of online experiments that work in any Internet browser without the need of any additional plug-in was proposed (Olmi, Cao, Chen and Song, 2011). To illustrate the new way of remote experiment development, several remote experiments were revamped under this unified framework, e.g. a new Smart Vibration Platform (SVP) remote experiment which is now used to teach students in mechanical engineering courses at the University of Houston. This remote control experimentation is aimed to offer student hands-on experience through the Internet on structural vibration control by using a Magneto-Rheological (MR) and Shape Memory Alloy (SMA) braces to control the vibration. In order to improve the control commands and experiment data transmission performance of the unified framework, a Comet solution via Socket.IO was developed (Chen, Osakue, Wang, Parsaei, Song, 2013). Socket.IO is a software package of Node.js which is implemented on the server side, and a new web socket protocol which lets the experiment communicate with Socket.IO is created for experiment control workstation. Nevertheless, the real-time experiment live streaming video is transferred via network port 1026 and the realtime control command and experiment data are transferred via network port 1029 based on this improved Comet solution. With this unified framework, users can remotely conduct the experiment by using most of Internet browsers on any portable device without installing any plug-in via the two special network ports 1026 and 1029 open. However, we faced some new challenges during the unified framework development and deployment. Normally, the special network ports are restricted and blocked by network firewalls in most universities, institutes and companies based on the security regulations. Only port 80 is open for accessing the web contents on web server. The real-time communication between browser and server, and traversing network firewall are two critical issues we strived to resolve. In this paper, we present a new framework with two innovative solutions to improve the unified framework for the remote experiment development. The new framework includes three parts: the client web application, the server application and the experiment control application. Socket.IO which is a JavaScript library of Node.js is used to support the real-time web application development and Node-HTTPProxy is used to support the traversing network firewall. To address the real-time experiment video transmission, HTTP Live Streaming (HLS) is used for real-time video transmission across network firewall.

The Improved New Framework for Remote Experiment The new framework is based on the Web 2.0 technology. The client web application is based on HyperText Markup Language (HTML), Cascading Style Sheets (CSS), and JQuery/JQuery-Mobile JavaScript libraries. The Mashup technology is used for user interface implementation. The client web application can be run in most of current popular browsers such as IE, Firefox, Chrome, Safari etc. The server application is based on Web Service technology, and is directly built on top of MySQL database, Apache web server engine and Node.js web server engine (Hughes-Croucher and Wilson, 2012, p.204). The server application uses JSON and Socket.IO which is developed based on web socket protocol to implement the real-time communication between the server application and the client-web application (Wikipedia, 2014). The server application runs on Centos 6.0 Linux server. The experiment control application is based on the LabVIEW, and uses Socket.IO for real time communication with server application. The experiment control application runs on experiment

-2004-

E-Learn 2014 - New Orleans, LA, United States, October 27-30, 2014 control workstation which runs Window 7 OS. Our new unified framework for remote laboratory development is based on three vital technologies, which are the Socket.IO, Node-HTTP-Proxy, and HLS protocol. NodeHTTP-Proxy is used for experiment data and control commands transmission and traversing firewall and the novel video transmission approach is based on HLS protocol for real-time system monitoring. In addition, the Mashup technology for user interface integration is employed in our client application. We use server-based Mashup technology to generate our client application. Server-based Mashup analyzes and reformats the data on a remote server and transmits the data to the user's browser. The architecture of our Mashup scheme is divided into three layers:  Presentation / user interaction: this is the user interface of Mashup. Our novel design uses HTML, CSS, JavaScript and Asynchronous JavaScript.  Web Services: the system functionality can be accessed using the API services. Our novel design used JSON-RPC, REST and SOAP.  Data: the data is handled in three ways, i.e., sending, storing and receiving. Our novel design uses JSON and Socket.IO for data transmission. Table 1 depicts the technical characteristics of the new unified framework in detail. Name

1 2 3 4 5 6 7

Technology/Protocol/Software Remark Http Proxy Node-HTTP-Proxy Part of Node.js Data Protocol Socket.IO Part of Node.js Real-time experiment video Http Live Streaming Protocol Transmission /FFMPEG /Segmenter software package Database MySQL Client – User Interface Mashup technology, JavaScript Server - Web Service Apache (2.2), Node.js (V1.0), JSON LtoN (LabVIEW to Node.js) Equipment Control LabView (V8.6) Table 1: Technology/protocol/software list for the new framework The system architecture of the new unified framework is shown in Figure 1.

Figure 1: The architecture of the new framework.

Vital Improvements of New Solution In this new framework, there are two key improved implementations, i.e., HTTP proxy implementation and real time video processing module implementation. For the real-time experiment control command and data transmission, we configure and run Node-HTTP-Proxy software application on the server side. The proxy application monitoring the network port 80 looks up the appropriate web server application request from the client and then proxies the data directly from the web server application to the client web browser. For the realtime experiment live steaming video transmission, we develop a new real-time video transmission approach via HTTP Live Streaming protocol and combines FFMPEG, which is a powerful cross platform command line video trans-code / encoding software package.

The Node-HTTP-Proxy for the network port sharing We need to address a complicated problem this is that we cannot set Apache and Node.js to listen on the same network port 80. In addition, we do not have an option to deactivate Apache and only run Node.js. To solve this issue, we propose to set up Node-HTTP-Proxy to get both Apache and Node.js working together and sharing the same network port 80 on the server side. Node-HTTP-Proxy is a full-featured HTTP proxy which is involved in Node.js server software package, and is a free and open source software package.

-2005-

E-Learn 2014 - New Orleans, LA, United States, October 27-30, 2014 Currently there are one Apache web application and one Node.js web application which work together in our web server. We use the Apache web application to generate the user interface framework, and the Socket.IO which is a module of the Node.js web engine to transfer the experiment data and experiment equipment control commands. In order to share the network port 80 for these two applications, we used the Node-HTTP-Proxy to handle the HTTP requests and data transmission. The Node-HTTP-Proxy is used the stream for HTTP requests and data transmission. The concept of a stream in Node.js lends itself beautifully to working with HTTP requests. One of the strengths of Node.js is its capability for streaming data; a great deal of performance can be achieved simply by tunneling the request and response streams to other destinations. Figure 2: Node-HTTP-Proxy Deployment Principle Figure 2 illustrates the deployment of the Node-HTTP-Proxy. The Node-HTTP-Proxy is working as the agent to transfer the request and data between the clients and web server applications via the network port 80. Node-HTTP-Proxy also has the excellent capability of proxy WebSockets protocol.

The live video streaming approach The purpose of the new approach is to improve the remote laboratory video transmission function and transfer the real-time experiment video via port 80. In order to achieve these goals, we develope a new real-time video transmission approach via a HTTP Live streaming protocol combined with FFMPEG, which is a powerful cross platform command line video trans-code/ encoding software package. To address the network firewall and flash plug-in issue, our new approach works by breaking the overall real-time experiment video stream into a sequence of small HTTP-based file downloads. Each download consists of one short chunk of an overall potentially unbounded transport stream. As the stream, the client may select from a number of different alternate streams containing the same video content encoded at a variety of data rates, allowing the streaming session to adapt to the available data rate. Briefly, the client (normally the Web browser) loads a playlist file of these video segments which is created following HLS protocol on the Web server (we use the Apache Web Server). The contents of this playlist are short clips (about 10 seconds) residing on a Web server. We need to create and maintain a playlist file and the short segments of the real-time video stream. Therefore, the sequence of small HTTP-based file downloading is transferred via HTTP Live Streaming protocol, and we use the FFMPEG software package to break the overall real-time experiment video stream into short download segments (Foresman, 2009). Finally, the real-time experiment video segments are transferred via HLS protocol through network port 80, and the real-time video will be reassembled in the Web browser and shown to end users. Figure 3: The new real-time video transmission approach Figure 3 illustrates the working process of the new real-time experiment video transmission approach. We need to setup FFMPEG software package on media server side, compile and install the Segmenter software package and configure the Apache Web server on HTTP server side. Upon building up the real-time experiment video processing and transmission environment, we resolve the real-time video transmission problem mentioned above.

Implementation of Remote SMA Experiment The Node-HTTP-Proxy implementation We integrate a core module, HTTP Proxy, on server-side to share network port 80. To achieve the transmission of the real-time live streaming video, real-time control command and the transmission of the experimental data across the network firewalls. The HTTP Proxy module is implemented by Node-HTTP-Proxy component which is a part of Node.js. In order to complete the HTTP Proxy integration, we need to finish the following tasks.  First, the Node-HTTP-Proxy software package needs to be installed on the server-side. Accordingly, the virtual hosts, which are normal on Apache web server software system, need to be set up.

-2006-

E-Learn 2014 - New Orleans, LA, United States, October 27-30, 2014

 Second, all virtual hosts shall be placed in a common directory (for example: "/localhost"). Then let the Apache web server software application listen to the public network port 80. After that, configure the port in file "httpd.conf" (such as changed "Listen 80" to "Listen other special port").  Third, all virtual hosts must be set to an IP based name Virtual Host (127.0.0.1) instead of using a port (such as HTTP://remotelab.qatar.tamu.edu:80) as defined in "extra/httpd-vhosts.conf".  Final, in the Node.js web server software system, the application/server (it is the node.js virtual host) that listens to the special network port (such as port 5001) which is different from Apache port (somewhat arbitrarily choice of port number) is created. Then in the "/localhost" directory, a file called "nodeHTTPProxy.js" is created. After finishing all of the steps mentioned above, Node-Http-Proxy.js is launched. Each of the node.js applications has a map file that contains the port that the application is listening to as well as a map that indicate the expected path which the application is being served on.

The new experiment data transmission protocol implementation based on Socket.IO In order to implement real time communication between the client application and the server application, a new Socket.IO based application transmission protocol is designed and developed. This new application communication protocol includes two parts, a client part that runs in browsers and a server part that runs in the web server. The two parts are developed with JavaScript language and also enhanced the real-time communication by the new Socket.IO based application transmission protocol. In this new application transmission protocol, a custom defined special communication instruction set is used. With the new instruction set, communication security can be guaranteed during the process of conducting the remote experiment. In the new protocol, brief instructions are used to control the experiment to improve data transmission performance. For the protocol implementation, two JavaScript program files are required: one for client application (runs in web browsers) and the other for server application (runs in web server). Then a new Node.js task was created to run the protocol in the server-side, and this server-side application must hold running status indefinitely. Because only the server-side protocol application holds the active status, it can ensure the normal real time communication. In client-side, there is a configuration file which defines and describes the communication instruction functions to support the client application normal operation in web browsers. As we mentioned above, the server-side protocol is run using ‘forever start’ command of Node.js in server-side. The server-side protocol enters into the active status, and the real time communication will be present during normal operation. The experiment data record function is implemented by using the new data transmission protocol. To illustrate the efficiency of new framework, we conduct a remote SMA experiment which provided a similar hands-on experience. The user can setup the experiment parameters and use slide bar to control current. The experiment data can be saved for post experiment processing. In this SMA experiment, the downloaded experiment data for the real displacement and the displacement reference is plotted in the same figure by using MATLAB. Figure 4 and Figure 5 depict the results of the displacement change of SMA in two tests from plug-in free remote experiment user interface.

-2007-

E-Learn 2014 - New Orleans, LA, United States, October 27-30, 2014

Figure 4: Arbitrary displacement control (with amplitude of 0.932in) in remote SMA experiment

Figure 5: Arbitrary displacement control (with amplitude of 0.646in) in remote SMA experiment

Sample Paradigms of the new solution The remote experiment user interface can be run on different platforms without any additional plug-in or software. To demonstrate the effectiveness of the new framework, a revamped remote SMA experiment is implemented into the new framework. Figure 6 illustrates the screenshots on desktop PC, iPhone and iPad when the users conducted the remote SMA experiment.

Desktop

iPhone

-2008-

iPad

E-Learn 2014 - New Orleans, LA, United States, October 27-30, 2014

Figure 6: Screenshots on PC and portable devices When the switch on the left corner of the web page is turned on, the user can move the slide bar to control the Desired Displacement value. The sensor output, which indicates the desired displacement volt value, is shown in the middle of the web page. With our novel data and video transmission solution, the real-time experiment video can be transferred to different platforms without firewall issue. Obviously, the remote laboratory system based on the new unified framework is able to take full advantage of the real instrument. The capability of running remote experiment on portable device such as Android phone, iPhone and iPad etc. will significantly increase the instrument utilization and let users gain insights by observing and interacting with the real instrument in an efficient way.

Conclusions In this paper, we presented a new unified framework for remote experiment development. We solved the real-time experiment video and real-time experiment control command and data transmission across network firewall issues through two innovative solutions we proposed for remote experiment development. The remote SMA experiment was successfully implemented under this new unified framework and the user interface can be run on most of Internet browsers in any platform without installing any additional plug-in. The capability of running remote experiment on portable device let users gain insights by observing and interacting with the real instrument in a more flexible way. This new unified framework will significantly benefit future remote laboratory development.

Acknowledgment This material is based upon work supported by the Qatar National Research Fund under Grant No. PRP 4-892-2-335. The data present, the statements made, the view expressed are solely the responsibility of authors.

References Boehringer, D., Jeschke S., Richter T. (2009). Lila - A European Project on Networked Experiments, the Sixth International Conference on Remote Engineering and Virtual Instrumentation Callaghan, M. J., Harkin, J., McGinnity, TM. and Maguire, LP. (2006). Client-Server Architecture for Remote Experimentation for Embedded Systems iJOE International Journal of Online Engineering, ISSN: 1861-2121, 2(4).

-2009-

E-Learn 2014 - New Orleans, LA, United States, October 27-30, 2014 Callaghan, M.J., Harkin, J., McColgan, E., McGinnity, T.M., Maguire, L.P. (2007). Client–server architecture for collaborative remote experimentation Journal of Networks and Computer applications, ISSN: 1084-8045, Volume 30,Issue 4, p 1295-1308. Chen X, Osakue D, Wang N, Parsaei H, Song G. (2013). Development of a remote experiment under a unified remote laboratory framework, QScience Proceedings (World Congress on Engineering Education 2013) July, 2013, http://dx.doi.org/10.5339/qproc.2014.wcee2013.7. Duro, N., Dormido, R., Vargas, H., Dormido-Canto, S., et al (2008). An Integrated Virtual and Remote Control Lab: The Three-Tank System as a Case Study, Computing in Science & Engineering, 10(4), 50-59. Ferreira, J.M.M., Sousa, E.L., Nafalski, A., Machotka, J. and Nedic, Z. (2009). Collaborative learning based on a micro-Webserver remote test controller, iJOE International Journal of Online Engineering vol. 5, no. Special Issue, pp. 18-24 1861-2121 Foresman, C. (2009). Apple proposes HTTP streaming feature as protocol standard, Ars Technica, 2009-07-10, in IETF.

Retrieved

Gillet, D., Salzmann, C., Longchamp, R. and Bonvin, D. (1997). Telepresence : An Opportunity to Develop Real-World Experimentation in Education, European Control Conference, Brussels, Belgium, Session WE-ML1. Hercog, D., Gergic, B., Uran, S. and Jezernik, K. (2007). A DSP-Based Remote Control Laboratory, IEEE. Trans. on Industrial Electronics, Vol54(6), pp. 3057-3068, ISSN: 0278-0046. Hughes-Croucher, T. and Wilson, M., (2012). Up and Running with Node.js (First ed.), O'Reilly Media, p. 204, ISBN 978-1-4493-9858-3. Olmi, C., Cao, B., Chen, X. and Song, G. (2011). A Unified Framework for Remote Laboratory Experiments, In Proceedings of ASEE Annual Conference & Exposition, Vancouver, BC, Canada Omli, C., Chen, X. and Song, G. (2011). A Framework for Developing Scalable Remote Experiment Laboratory, In Proceedings of World Conference on E-Learning in Corporate, Government, Healthcare, and Higher Education 2011, pp. 2045-2050, Honolulu, Hawaii. Wikipedia (2014). Socket.IO – Wikipedia, the free encyclopedia, Online,http:// en.wikipedia.org / wiki/Socket.io, accessed September 1, 2014.

-2010-