contribution 153 a

8/2/2019 Contribution 153 A

1/5

From online to smart device

From online experiments to smart devicesc. Salzmann and D.Gillet

Ecole Polythecnique Fcderalc de Lausanne. School of Engineering. Switzerland

Abstract-Online experiments have been available for morethan a decade. The integration of online experiments tocollaborative environments is more recent. The wealth ofclient application/environments, the versatility of possibleinteraction protocols/technologies and the needs for moreautonomous actions impels the evolution of onlineexperiments to the smart device concept. This paper reviewsthe evolution of an electrical drive experiment andpresented the requirement for turning online experimentinto smart devices.Index Terms-Agent, collaborative environment, onlineexperiment, smart device.

1 . INTRODUCTIONOnline experiments are typically used by brokers toprovide remote experimentation to distant users. Forexample, the access to an online experiment during a livedemonstration in classroom. Online experiments are oftenused in control, robotic and mechatronic education forillustrating theoretical principles and deploymentmethodologies. As example, the different control designand implementation steps taught to students in controlcourses (system identification, controller design, real-time control, performance validation, etc.) can beefficiently carried out remotely on mechatronic systemsas they exhibit visually observable dynamical behaviors.Remote experimentation solutions are based on a client-server approach where the server is connected to thephysical equipment and the client application is connectto the server via the Internet. The user interface can be ofvarious forms but it is generally proposed through a webbrowser. The objective of a remote experimentationsolution is to make the student interaction with the distantsystem as close as possible as the actual work on the realequipment. Collaborative environments are proposed tosupport the distant user learning process. Theseenvironments integrate various services to streamline theuser experience and to help the user environmentappropriation. To provide a tight integration of remoteequipments within collaborative environments specificcares are to be taken for the interface, the functions andthe communication. This customization leads to a veryspecific solution that is difficult or impossible to integratein another collaborative environment. The concepts ofsmart devices are used to expend the online experimentscheme such that the proposed solution is adaptive,autonomous, as envisioned in the Internet of Thingsrealm.

REV2008 - www.rev-conference.org

This paper is organized as follow: the physical equipmentlocally controlled is first presented. Then in section III, acommunication component is added to permit remoteaccess. The integration of online experiments intocollaborative environments is presented in Section IV.Section V presents the smart device concept applied toonline experiments and its requirement.

II. PHYSICAL EQUIPMENT AND LOCAL ACCESSThe physical equipments remotely controlled are oftenmechantronic devices with moving parts as they exhibitvisually observable dynamical behaviors. For examplethe laboratory-scale electrical drive (Fig. 1) is used inmany textbooks and courses to illustrate automaticcontrol theory. This setup consists of a DC motorequipped with a digital encoder. This motor drives a brassdisk acting as the load. The angular position is measuredwith the help of a digital encoder connected to the motoraxle. Along the same axle, an enlarged rotating diskpermits an easy visualization of the motion. This enlargeddisk and the rotating load motion are captured by a videocamera. The whole hardware has been designed such asit is fully controllable from a connected computer.Similarly, the hardware state can be diagnosed from theconnected computer. For example, beside the standardmotor control, the main power can be switched on and offfrom the connected computer. Likewise, in addition to therequired disk position and speed measurements,diagnostic signals informing about the power status canbe read from the connected computer.

Figure 1. Laboratory-scale electrical drive.

Physical equipments are generally controlled by anexternal computer connected via data acquisition board
http://www.rev-conference.org/http://www.rev-conference.org/


2/5


(DAQ). Depending on its complexity and computationalresource requirement, the control of the equipment canalso be performed via an on-board micro-controller. Thislater solution offers less flexibility than the former one.The considered physical equipment is used by students toapply control theory and learn controller design. Forexample, the experimentation protocol consists inchoosing the right set of parameters to position the loador to impose a rotating speed according to somespecifications. The PID controller is implemented as areal-time task that communicate with both the physicalequipment and the graphical user interface (CUI) [1].With the help of the graphical user interface, the userscan experience the effect of the various controllerparameters and see their effects on the physicalequipment. Figure 2 shows the user interface of theapplication that locally controls the laboratory-scaleelectrical drive. It is written in LabVIEW [2]. The upperpart displays the acquired measurement in a scope area.The bottom part let the user modify the controllerparameters and the reference signal.

Renote_Cli~nr_7.0 F ro nt P an -e l ~I.II!!J 11JPt~'PPliciltion Font I~I~~~~Experiment I Senin~s 1 Information J

scconc" ' _ "lUll la_uo~ f c _ OARVI DPred.2 O ~ i "~~ : ~ D _ ) r L O O J " "o_!c~ J- o-~ D :[TI] :G2]STOP

Figure 2. Local control of the electrical drive

III. FROM LOCAL TO REMOTE ACCESSProviding remote access to physical equipmentscontrolled locally by a dedicated computer is fairlystraightforward assuming that the computer is connectedto the Internet. Depending on the required degree ofinteraction between the distant user and the physicalequipment both turnkey and customized solutions can beenvisioned.

A. Turnkey SolutionsNowadays many turnkey solutions are proposed by

commercial applications. The quickest solution is the useapplication that enable the sharing a distant computerscreen (VNC, Remote Desktop, Timbuktu, etc.). While


easy to implement this solution generally suffers a highbandwidth usage. Another drawback is that the usercannot see the physical equipment. Visualizing thecontrolled equipment is considered a key feature todifferentiate simulation from real experimentation. Alsodirectly accessing the remote server may grant too muchright to the distant user permitting to act on aspect he/shenot supposed to.Another kind of turnkey solution relies on specific

applications that are able to generate a remote view of thelocal CUI, this view is generally displayed in a webbrowser. The server application can either generates adynamic web page or required specific client applications(LabVIEW remote panel). Both solutions can be enabledwith only a few mouse clicks but suffer the samevisualization drawback as the screen sharing solution.While a video stream coming from an IP camera may beembedded to the web page containing the deported localview, the information synchronization between thesources of information is added to the potential bandwidthproblem.

B. Custom solutionsCustom solutions permit a finer control of all the aspectsinvolved in remote experimentation, this at the cost ofadditional developments to create the client applicationand to add the network communication layer to thelocal [3].Various technologies can be used to implement the clientapplication. Web based technologies (Java, Flash,Silverlight, QuickTime, ActiveX) are the most widelyused since they are ubiquitous and often pre-installedwithin the web browser.Depending on the client application requirements, thechosen technology should provide the following features:

display CUI elements, (button, etc)ability to get user actions/events (mouse click)support communication protocol (TCP,UDP)timing synchronization (threads, timers)

As of today Java is the most versatile option that permitsthe finest control of the client application. A solution thatonly uses standard web technologies (CSS, Ajax) withoutthe help of plug-ins is possible provided that the webtransmission protocol (HTTPITCP) does not constrainsthe envisioned communication. Java provides the fullcontrol over the above features necessary to implementan advanced remote experimentation client. It especiallypermits to implement alternate transmission protocol(UDP) and allows a tight synchronization between thevarious flow of information (video, data).Figure 3 presents a java applet that enable to control thedistant laboratory-scale electrical drive. The providedinterface permits the user to change the variousparameters of the PID controller and see its effects inreal-time via the oscilloscope area and the videofeedback.

2


3/5


The main adjunctions to the distant application thatlocally control the physical equipment (Fig 2) are thevideo acquisition and transmission layer that allowsremote clients to communicate with the onlineexperiment. With these additions the local applicationbecomes a server application. Additional requirementsand best practices are presented in [4].nn () eMer,ion Appl~t Cient~ ~ Ikl r+ll!...i!!~/i128.178S.103/apPlet'i/lerl'[>[li~ntap.Plet.htmI5~rlJerIP~""~ "C=O"":;::-"---

:~I77... ~

:>!in, 2.11#. 11124. i ;

Kp_ T_ Td_ Uol!I!II fc_

servo position: Athata: 1 TaGJ: 0.2:3

Figure 3. the client application implemented as ajava applet

IV. WEB 2.0 SOCIAL SOFTWARE FOR COLLABORATIVELEARNING AND INTERACTION WITH ONLINE EXPERIMENTS

The additional flexibility provided by remoteexperimentations is highly appreciate and permits distantusers to manage the remote experimentation sessions attheir own pace and from their own location [5]. Onedrawback is that the learning modalities often found oncampus should be emulated. Collaborative learningsupport should be provided, as well as some forms oftutoring and assistance. Collaborative environments suchas emersioti [6] and [7] support the activities with onlineexperiments by providing additional services such asshared spaces for saving measurements, discussionforums, live support, etc. The online experiments need tobe specifically adapted to maximize the benefits offeredby collaborative environments. Not only the clientapplications needs to be adapted, but also the serverapplication. For example authentication is often requiredby collaborative environments, thus the client and/or theserver applications must be adapted to supportauthentication. Similarly, saving data in a shared spacerequired specific protocols that may not be presentsinitially. When possible, some or all the requiredadaptations could be implemented by a proxy applicationthat bridges both worlds. This translation is often done atthe cost of performances. This proxy application bridgingmechanism can be generalized to concept of agent thatworks on the behalf of users or in the presented case onthe behalf of the online experiment server [8].Figure 4 shows the remote experimentation agentworking on the behalf of both the user Chris and the


equipment RT-201 within the e1ogbook {refl}collaborative environment. The measurements acquiredwith the help of the agent (center of Fig. 4) are directlysaved within the shared space (right column of Fig. 4)and are be visible by the members (left column of Fig. 4)of the given activity (top of Fig. 4). The agent has beengranted the right to directly save measurements in theshared space after it authenticated using the providede1ogbook mechanism.

Invite I I QuitFigure 4. Remote experimentation agent in eJogbook

The original online experiment does not know about thee1ogbook it is only aware of the e1ogbook agent. Usingthe agent concepts, the online experiment could beinterfaced by various collaborative environments butwould require a dedicated agent for each newenvironment. To alleviate this restriction and to permit"any" clients to access the online experiment, all theagents should be hosted at the server side. While this isnot directly feasible since all agents are not known beforehand, the structure to support multiple types ofconnections, protocols, modes of operation and interfacesin an autonomous and self-contained way should beimplemented in the server. A server connected to physicalequipment with the above capabilities and the ability tointeract autonomously with other machines is called asmart device.

V. SMART DEVICESSmart devices can be described as devices that have someautonomy to perform actions. Theses devices often havesensors and/or actuators and support communication withother devices. The interconnection of smart devices andother intelligent objects sketches the Internet of Things.The Internet of Things is a metaphor that envision theconnection of all existing objects for the universality ofcommunication processes, for the integration of any kindof digital data and content, for the unique identification ofreal or virtual objects and for architectures that providethe communicative glue among these components [9].Thomson suggested that smart devices needs some or allof the following capabilities: i} communications, ii}sensing and actuating, iii} reasoning and learning,iv } identity and kind, v} memory and status tracking [10].

3


4/5


A. Requirments for turning online equipment into smartdevices

Physically, the considered smart device is made of theadjunction of the controlling computer -the server-connected, on one side to the physical equipment and, onthe other side to the Internet. The capabilities required forsmart devices controlling physical equipment are twofold.The first set of requirements is related to the physicalequipment. The physical equipment should be identifiableto define what kind of equipment is connected. Also theequipment should be fully controllable and diagnostic-able by the controlling computer. The full controllabilityof the physical equipment may not be exposed to theoutside world due to security reasons. Controllability alsoimplies that it is always possible to place the equipmentin a know state. Other requirements such as reliabilityand maintainability should also be considered.The second set of requirements is related to theinteraction of the controlling computer and the outsideworld. This interaction implies that first the computer isconnected to the Internet and capable of understandingincoming requests and to reply to them. It should also becapable of some autonomy to report for example alarmsor its status. Security and authentication must also beprovided. It should not be possible to temper with thephysical equipment from the outside world. This is alsotrue for the hosting computer and the engagedcommunications. In the considered case, the server maypropose a graphical user interface to interact with theserver.The communication requirements suggest that the serveris able to talk any low level protocols such as TCP orUDP to get the requests and send replies, but also highlevel protocols or technologies such as HTTP, XML,REST, FTP, XML-RPC, WSDL, POP, MAIL, RSS, etc.to understand the requests. It is definitely not possible toimplement all possible protocols, but the structure tohandle new protocols should be in place to minimize thedevelopment effort. The next section presents the chosenset of protocols to be implemented and the rationalbehind these choices.

B. Smart device exampleThe proposed smart device is an extension of the onlineexperimentation server described in section II. Initially,the sole task of the server was to control the physicalequipment locally. Then a communication componentwas added to send measurements and to receiveparameters from a home-built application using the UDPprotocol. The acces from a web browser required thewriting of a Java applet and the associated servermodifications. The integration of remoteexperimentations in collaborative environment impliesthe adjunction of new functionalities and new protocolsand the use of the agent concepts. The globalmanagement of the available resources was also required


to dynamically spread the load among the availableonline equipments leading to additional modifications atthe server side.The current server is a smart device with an evolvingstructure that guaranty compatibilities with existingsolutions while streamline the addition of new ones. Onthe physical equipment side, the server only expose alimited set of actions that are validated prior to itsapplication on the physical device. Similarly the serveronly provides aggregated information regarding thephysical equipment to the outside world.The former client applications can interact with the smartdevice by sending UDP packets that contains parametersfor the implemented controller. As a reply, clientapplications receive two UDP streams, one for the videofeed and the other one for the measurements feed.

The current collaborative environments (emersion andelogbook) do not have specific interface to the smartdevice. This interface is provided by the smart device inthe form of a Java applet. The smart device is also able tohandle the user credential to directly interact with thecollaborative environment. This interface can also beused independently by web browsers without link tocollaborative environment. The interface functionalitieswill be adapted accordingly, for example user would onlybe able to save measurements on the user desktop and notin the collaborative environment shared space.In addition, the sever features awareness information tothe outside world. These information cover, among otherinformation, the sever status, connections statistics andusage statistic. Client applications can get the aboveawareness information through various channels. Forexemple by opening a raw TCP connection to the server.Alternatively the client application can use a providedweb service using the XML-RPC protocol. An RSS feedwith the above information is also provided. Last but notleast, it is possible to send an email to the server to getthe above information. Interfacing programs via email isnot new but has been forgotten over the years. Howeveremail support provides a simple and unobtrusive interfacethat is generally ubiquitously available [11].The mechanism implement for the awareness informationis also available for the other streams of information(parameters, measurements and video).The above information exchange relies on a request-answer mechanism. The smart device is also able to pullinformation to given recipients. In case of self-diagnosedmalfunctions the server can send an email and an SMS. Atypical malfunction is the physical equipment mainswitch set to OFF. The power status of the equipment isregularly checked and appropriate actions are taken oncediscovered.

4


5/5


The collaborative environment may deal with manydevices. An auxiliary application dynamically redirectsthe collaborative environment agents to available devices.The smart device informs this auxiliary application aboutits status. If the auxiliary application is unavailable and ifthe smart device already in use, the smart device is ableto re-route the agent requests to neighbor equipments .

VI. CONCLUSIONSThis paper presents the evolution of an electrical drivethat is initially controller locally by a computer. Variouscomponents are added to permit a remote access. Theonline experiment is then integrated to collaborativeenvironment. The concept of agents is used to permit theonline experiment to work on the behalf of the userwithin the collaborative environment. The performedactions can be controlled when the user decided to savemeasurements at a given time or autonomous whensending an alarm. If the agent performing autonomoustask is part of the server, the resulting tandem can becalled a smart device. The requirements for turning onlineequipment into smart device are then presented. Anemphasis is placed on the communication side that shouldaccommodate to many technologies and protocols.Finally an example depicts the interaction between asmart device and various client applications.

REFERENCES[1] Salzmann, C. ; Gillet, D. ; Longchamp, R. ; Bonvin, D.,

"Framework for Fast Real-Time Applications in AutomaticControl Education", 4th IFAC Symposium on Advances in ControlEducation, p. 34S-3S0, 1997

[2] http://www.ni.com/labview/[3] Salzmann, C. ; Gillet, D. ; Huguenin, P., "Introduction to Real-

time Control using LabVIEW with an Application to DistanceLearning", International Journal of Engineering Education, vol.16,num. 3, 1999,p.2SS-272

[4] Salzmann, C., Gillet, D., "Challenges in Remote LaboratorySustainability", International Conference on EngineeringEducation, ICEE 2007, Coimbra - Portugal, 3-7 September 2007.

[S] Salzmann C., D. Gillet, P. Scott, and K. Quick, "Remote lab:Online Support and Awareness Analysis", 17th IFAC WorldCongress, Seoul, Korea, July 6-11, 200S.

[6] Nguyen Ngoc, A. V. , Y. Rekik, and D. Gillet. "A framework forsustaining the continuity of interaction in Web-based learningenvironment for engineering education", World Conference onEducational Multimedia, Hypermedia & Telecommunications ED-MEDIA 200S.

[7] 7 elogbook[S] Salzmann C., C.M. Yu, S. El Helou, and D. Gillet, "Live

Interaction in Social Software with Applicat ion in Collaborat iveLearning", :I'd International Conference on Interactive Mobile andComputer Aided Learning, Amman, Jordan, April 16-lS, 200S.

[9] Federal Ministry of Economics and Technology. 2007. Europeanpolicy outlook RFID, draft version: Working document for theexpert conference "RFID: Towards the Internet of Things". June2007.

[10] Thompson, C. W. 200S. Smart devices and soft controllers. IEEEInternet Computing, vol. 9, issue 1, Jan.-Feb. 200S, pp. S2-SS.


[11] D. Gillet, C.M. Yu, S. El Helou, A. Madina Berastegui, Ch.Salzmann, and Y. Rekik, "Tackling Acceptability Issues inCommunities of Practice by Providing Lightweight Email-basedInterface to the eLogbook, a Web 2.0 Collaborative Activity andAsset Management System", 2nd European Conference onTechnology Enhanced Learning, D Crete, Greece, September 17-20,2007.

AUTHORSCh. Salzmann is with the Ecole Polytechnique

Federale de Lausanne, Switzerland (e-mail:christophe. [email protected]).

D. Gillet is with the Ecole Polytechnique Federale deLausanne, Switzerland (e-mail: [email protected]).

5
http://www.ni.com/labview/http://www.rev-conference.org/http://www.rev-conference.org/http://www.ni.com/labview/

contribution 153 a

Documents