1. Deploying Interactive Remote Labs Using the iLab Shared Architecture James Hardison, MIT - CECI Frontiers in Education, October 22 - 25, 2008

2. Motivation for the iLab Project  Laboratory experiences represent an enormous educational value  Remote labs are a good complement to hands-on experiences  But, building a new remote lab from scratch is hard  The iLab Project: Provide a standard architecture that eases the development and sharing of remote laboratories.

3. A Brief History of the iLab Project Adoption of ISA increasing worldwide ► 1998: First Individual Labs Developed 2004: iLab Shared Architecture (ISA), Compliant Batched Labs Released 2007: Support for Interactive Experiments Added to ISA

4. Benefits of the iLab Shared Architecture  Provides a set of generic functions, eases development  Provides a standard, distributed platform for lab deployment, eases sharing  Enables single sign-on for students who use multiple iLabs Batched iLabs allow certain simplifying assumptions:  Communication model  Execution model Interactive iLabs are a little more complex…

5. Supporting Interactive Experiments Interactive experiments, by their nature…  …require real-time control. Direct client to lab server connection needed (possibly high-bandwidth, possibly proprietary)  …are performed in human-time. Longer periods of single user control A revision to the iLab Shared Architecture was necessary to provide services for interactive experiments.

6. Topology of Interactive Experiments in the iLab Shared Architecture iLab Service Broker orchestrates access to a set of distributed, stand-alone services for…  Experiment Storage  Scheduling  Cross-service authentication (Ticketing) Service Broker sets up the experiment session and then steps out of the way.

7. The Experiment Storage Service (ESS) A generic stand-alone service responsible storing student experiment information  Lab configurations, input parameters, results Service Brokers, Lab Servers and Clients all interface to an ESS  Service Broker responsible for record management  Clients & Lab Servers contribute to the record A single ESS may service many iLab installations

8. Scheduling Services Used to manage student access to the lab. Composed of two complementary services:  Lab-side Scheduling Service (LSS)  Allocates available lab time to sets of students.  User-side Scheduling Service (USS)  Reserves blocks of available time for individual student use. Service Brokers manage connections between USS and LSS pairs

9. Ticketing Provides a common authorization system for systems in the iLab Shared Architecture, based on the following ideas:  Service Brokers authenticate users and can permit access to ISA resources by issuing Tickets.  Agents seeking access receive only a pointer to the Ticket (Coupon).  Only issuing and redeeming agents are able to access Ticket information. Ticketing is used to manage access to all ISA systems.

10. Developing Interactive Labs for the ISA  By design, few technical constraints are placed on lab development  Labs can have drastically different requirements  One size does not fit all  LabVIEW Integrated Interactive Lab Server (LVIILS)  Provides a toolkit for building a LabVIEW based lab using the ISA  Enables LabVIEW VIs to take full advantage of ISA services  Existing VI can be converted to an iLab in a matter of hours  Development on other platforms follows similar path to that of the LVIILS

11. Deployed Interactive iLabs: Force on a Dipole Enables students to observe the behavior of a magnet suspended by a spring between a Helmholtz coil  Targeted to freshmen Physics students at MIT  Built using LabVIEW and LVIILS  Successful test deployment Spring 2008, full scale deployment (~600 students) this Spring.

12. Deployed Interactive iLabs: Nuclear Reactor Exposes some functionality of the MIT Nuclear Research Reactor  A variety of experiments are available in the iLab  Also built using LabVIEW  To be used in MIT Nuclear Engineering and Physics courses and, eventually, by select secondary schools

13. Ongoing Work and Conclusions What we’re working on now:  Develop a unified architecture that will support both Batched and Interactive iLabs (recently completed).  Further refine services for Interactive iLabs on the ISA  Support development of Interactive iLabs at Project partner institutions. In conclusion…  The iLab Project has developed a platform to support the development and deployment of Interactive remote laboratories.  A toolkit has been developed to enable the rapid development of LabVIEW based experiments.  This work will drastically increase the number of iLabs available to students. For more information, see http://ilab.mit.edu/wiki