Phillip D. Long and Stephen C. Ehrmann
As the rich collection of creative and effective open source projects described in this Carnegie volume demonstrates, innovation comes in all shapes and sizes in higher education today, enabling access to resources, pedagogy, and devices. This chapter describes one particular type of open source innovation—middleware called iLabs (supported largely by the Microsoft-MIT iCampus Alliance; see http://icampus.mit.edu) that enables users to run experiments remotely over the Web. First, we will briefl y describe the development of remote labs at MIT and the development of the iLabs middleware. Then we will discuss some of the factors that have hindered the spread of this potent use of the Web, and draw a few tentative conclusions about how these issues affect the dissemination of educational innovation based on open source software.
Remote labs, such as those made available via iLabs, extend access to laboratory experiments, making them available 24/7 whenever students wish to use them. They also enable faculty to bring experiments into lecture to explore real “what if” scenarios, without needing to have laboratory equipment in the classroom. Remote labs can provide labora- tory experiences with devices that otherwise would be impossible for students to manipulate (for example, controlling expensive or dangerous equipment). Sharing expensive laboratory resources can provide students with more opportunities to interact with experiments and confront the messiness of real data, not simulations. This is a crucial step if the intent of the experiment is to give students the opportunity to experience the difference between modeling the world versus understanding how the real world actually works.
Yet with all of this potential, the wider adoption of remote labs gener- ally, and iLabs in particular, has been limited. This is the case even after fi nancial incentives have been offered to faculty and institutions around the world to adopt iLabs-supported remote labs and pilot their use in courses.
Why has the dissemination of open source iLabs middleware received such limited uptake and interest? We will return to that question. First, however, we need to summarize the history of iLabs development at MIT.
Remote Labs—History at MIT
Accessing remote instruments through the Web has been an interest since the fi rst Internet browsers were developed (Berners-Lee and Cailliau, 1990). Various programs to provide Web-based remote access to scien- tifi c instruments quickly emerged (for example, Aktan et al., 1996; Goldberg et al., 1994).
In 1998, Professor Jesus del Alamo, an electrical engineer, was unaware of these fl edgling educational innovations. Like most engineering faculty at research institutions, his collegial connections around the world, his reading, and his conference participation were oriented toward engineer- ing research, not education. Del Alamo, an experimentalist, had what he thought of as a “bit of a crazy idea” for one of his courses: to allow students to create and run a real experiment, not just a simulation, by using a Web browser to control the apparatus. It was already becoming common for students to use lab instruments by programming a computer sitting next to the instrument, without ever touching the instrument itself. LabView (National Instruments, See http://www.ni.com/) provided access to experimental equipment for students sitting next to the devices. Why not extend that an arbitrary distance through the Internet?
Economic motives existed alongside the pedagogical reasons to con- sider remote use of laboratory equipment. In a traditional laboratory course serving 40 students, students might come for two hours and work in pairs on experiments (so 20 identical equipment setups would usually be needed). Staff would have to be available to set up this expensive equipment for students in advance (20 setups for each class session); the equipment would then lay idle, obsolescing, until its next use. The expen-
sive space devoted to the laboratory would also lay idle (See Pope and Anderson, 2003, for an economic analysis of undergraduate engineering laboratories at the University of Pennsylvania, as well as an analysis of the alternative approach to organizing laboratories developed there). And lab assignments could only be done during the brief class period allotted for work in the laboratory; experiments that might require student attention periodically over many hours simply wouldn’t work in a traditional undergraduate course. Small wonder that lab work is rare.
By contrast, an iLab would allow students to use a single piece of equipment, one after the other, 24/7. For lecture courses like del Alamo’s, a remote lab would enable true experiments to become part of the course’s homework. Del Alamo realized that, with such a strategy, stu- dents could do research with the same equipment that professionals used, rather than affordable, simplistic student versions of the real thing.
In March 1998, del Alamo used a small grant from Microsoft to hire an undergraduate student through the Undergraduate Research Oppor- tunities Program (UROP; MIT has an extensive program to encourage faculty and others to engage undergraduates in professional work in exchange for money or academic credit; about 85 percent of all MIT undergraduates have participated in at least one such UROP project.). This student, Lane Brooks, designed the architecture for Web control of a Microelectronics Device Characterization Laboratory in just a few months, using equipment from del Alamo’s research to do the actual experiment and a donated computer to control the experiment. The iLabs project has used productively and widely the talent among MIT undergraduates in the development of the iLabs software architecture.
Impressed and excited, del Alamo decided the new laboratory setup was reliable and solid enough to use in the fall term with Integrated Microelectronic Devices, a graduate student class of over 30 graduate and undergraduate students from EECS and the Materials Science Department.
In spring 1999, del Alamo used an improved version of this lab with an undergraduate class of about 90 students, Microelectronic Devices and Circuits. Although reactions were somewhat mixed and students had discovered new ways to break the lab, del Alamo was nevertheless encouraged. Del Alamo applied for funds from the MIT Alumni Fund
for Educational Innovation program to continue his work in developing Web labs. The success of his fi rst lab also enabled him to apply success- fully for a donation of equipment from Hewlett Packard. This equipment donation allowed him to run his Web labs on a different machine than was used for his research. The results of this foray encouraged him to delve more deeply into evolving the idea.
Later in 1999, Microsoft Research and MIT began the $25 million iCampus Project (See http://icampus.mit.edu/). iCampus’s goal was to support the development of new technologies to support teaching and learning. Five iLabs were funded with separate iCampus grants, each to a different faculty member, including del Alamo’s work in electrical engineering. These included a heat exchanger experiment in Chemical Engineering, a polymer crystallization experiment in Chemical Engineer- ing, a “fl agpole” sensor experiment, and a “shake table” experiment in Civil Engineering.
Because the developers of these early projects made their own decisions about design, their programs for doing common tasks (for example, creating accounts for students, authorizing access to the experiments, and storing results of experiments) were each developed independently and in different ways. This is a common consequence of innovations developed by separate labs or developer teams, even when working on the same content area—one that characterizes many open source projects.
Scalability in Online Experiments
The initial iLabs experiments followed a pattern that is typical in academe: Each lab was built by a team consisting of a lead faculty member (the domain expert), developers, and related technical experts (usually stu- dents). They used the technology and design approaches most familiar to them without regard to the other teams building experiments in their respective discipline areas. They created useful and functional labs. Yet each required a mechanism for authenticating the user, authorizing access to the experiment, and managing the resulting data sets generated. And each did this in a reasonable but unique way.
Building experiments in this fashion is a time-honored tradition. But it makes the cost of constructing the nth+1 experiment no different from
the software, is usually the responsibility of the faculty member who developed the lab, because the software is likely to be unique and perhaps not well-documented.
The problems multiply if the faculty member wants to share access to the experiment with colleagues, because the developer faculty member must manage the external accounts, pay attention to the course schedules of faculty from around the world using the experiment (faculty who may be in different time zones and may not speak the same language as the developer), and manage data created and stored on servers. In other words, when the developers each create their own infrastructure, there are enormous disincentives for sharing experimental equipment over the Web.
The iLabs Architecture
The central contributions to the iLabs shared lab architecture (Harward et. al., 2004; Harward et. al., 2006; Harward et. al.,2006b are 1) a dis- tributed design and 2) a set of reusable Web services to provide functions required of any online remote lab.
Distributed Design The fundamental insight into a sustainable and scalable proliferation of remote labs was to divide the responsibilities inherent in managing these labs into two parts.
1. One set of activities revolves around the actual experimental equip- ment and the domain expertise associated with instrumenting the experi- ment for network access.
2. The second focuses on management of the access to the remote lab, account creation, use policies, and data sets resulting from use. Connect- ing the experiment to the network is properly the responsibility of the owner of the lab equipment being shared. However, the experiment owner should be shielded from and not responsible for users beyond her or his own students. The latter ought to be in the hands of the user community accessing the equipment, wherever in the world they reside.
This division of responsibilities is built into the iLabs architecture shown in fi gure 4.1.
The iLabs Service Broker is responsible for accounts, usage policies, and data collected from batch-oriented experiments. The owner of the
lab experiment puts it online using a dedicated lab server. The Service Broker enables lab owners to share excess capacity of their experiments without being penalized for their willingness to do so (where “excess capacity” is a result of experiments that have short execution times rela- tive to the user interaction required to confi gure them). Where does this excess capacity come from?
Students do homework, whether problem sets or remote lab experi- ments, the same way around the world. They often wait until the last minute before the homework is due before doing their experiments. Figure 4.2 shows the pattern of students accessing the microelectronics experiment during the week, with the due date at 2:00 p.m. on Friday (the arrow). Peak server load on the experiment server immediately precedes that deadline. The remote lab designer needs to plan for spikes in peak usage to accommodate this behavior.
Here’s the good news: Creating capacity to meet occasions of peak demand creates unused capacity for all the other hours and days. That’s “found” capacity that can be potentially shared with other instructors or learners who might need to use this equipment.
iLab Service Broker
Campus network Campus network Clients Internet Lab servers Figure 4.1
Web Services When building experiments for remote access, common requirements are encountered. For these the iLabs team has designed and coded a reusable set of Web services (see table 4.1.)
In a typical confi guration, a campus using iLab-based experiments will run a Service Broker administered by local IT staff. This Service Broker can access multiple lab servers located both on one’s local campus as well as on campuses remote from the users. The students’ accounts and
14 12 10 8 6 4 2 0 0:0 0 12 :0 0 0:0 0 12 :0 0 0:0 0 12 :0 0 0:0 0 12 :0 0 0:0 0 12 :0 0 0:0 0 12 :0 0 0:0 0 12 :0 0 0:0 0 12 :0 0 0:0 0
Number of Student Users Per Hour
Friday Saturday Sunday Monday Tuesday Wednesday Thursday Friday 6.012 Students
6.720 Students
Figure 4.2
Creating sharable capacity Table 4.1
Web services in the batch iLabs architecture Web service Description
Authentication Validate who can access the experiment
Authorization Determine if a given user has permission to access a particular experiment
Experiment data storage Manage individual user data storage and persistence
their experiment storage reside on their own Service Broker regardless of where the experiment itself is executed. The lab server team need not be aware of which student is using the equipment at any given time, but may be assured that the student comes from an approved campus. Authentic Tools and Interface Design The options offered by remote labs also include the ability to use the same research equipment that professionals use. It is hoped that students will thereby begin to try out the identity of being a professional and, from there, take other steps to enter the profession. The Center for Authentic Science Practice in Education (CASPiE) project at Purdue University is anchored around this notion of authentic learning with professional tools and student engage- ment in “real research with real tools” as central to their work.
However, the software written for the practicing professional is often designed to provide great fl exibility and granular control—desirable attributes for the practicing scientist but frequently a learning curve of signifi cant incline to the novice learner. The iLabs environment allows a great deal of latitude in how the student learning experience is presented, though it affords this at a cost in development time and expertise. Adding value through thoughtful interface design, an example The University of Queensland (UQ) teaches a third-year engineering course in control theory. In this course, a signifi cant laboratory exercise is pre- sented through the introduction of an inverted pendulum experiment. This experiment requires students working in teams to write a program (using MatLabTM, in this instance) to control an electric motor from
which hangs a pendulum arm. The pendulum has two sensors connected to it to provide exact information on its position. The student’s task is to write a program that swings the pendulum arm back and forth until it inverts to the vertical position, and when it reaches this point, to change the inputs to the controlling motor to try and balance the pen- dulum arm in the vertical position (see fi gure 4.3).
Typically the students spend fi ve weeks in the engineering lab to perform this experiment. The data the students receive from the instru- mented beam are the two angles that describe the beam’s position. By observing the outcome of their experiment, they must adjust their control program and rerun the code to see if they have brought the beam closer
to vertically balancing. Data from UQ indicate that about 5 percent of the teams successfully complete the application and get the beam bal- anced, though much learning is accomplished.
Joel Carpenter, a third-year undergraduate who had never taken the course, began the task of creating an iLab implementation of the inverted pendulum experiment. Carpenter brought two key insights to the task, having recently sat in front of the apparatus and watched students strug- gling to complete the experiment. The fi rst was to add a state diagram to the user interface so that when the program failed, there was a starting point to look at the code to make adjustments. Just knowing what state the pendulum was in when it failed gave insight into where to attack revising the program.
The second insight was born from the frustration of the real lab experi- ence. When running the code and observing the behavior of the pendu- lum, then changing the code again, the feedback is largely numerical. You can see the pendulum swinging differently in response to each code modifi cation for each run, but comparing across runs is impossible. Or is it?
With a webcam on the experiment, you can observe each run as though you were in the lab. That’s useful. But the insight Carpenter brought to the problem was recognizing that the actual pendulum arm could be digitally removed and replaced by an animation of the arm Figure 4.3
The inverted pendulum experiment by the University of Queensland (Joel Carpenter, student developer; Geir Hovland and Mark Schulz, faculty project coordinators)
driven by the data. If this can be done, then it’s also possible to overlay the image with several animations of the arm controlled by data from multiple runs of the experiment. One can see the impact of code changes by comparing one run to another visually. The application interface is shown in fi gure 4.4.
This insight provides a pedagogically more useful learning environ- ment than that available from the interface of the original experiment. This is a key attribute of learning-centered application design that can add value to the student experience beyond that provided by the original equipment confi guration. Assessment of the students using the inverted pendulum experiment led to the observation that using iLabs “was better than being there.” Students received more useful feedback from the thoughtfully designed interface than they had in the “real” equipment on the lab bench. One result of this implementation was that the percent- Figure 4.4
The user interface for the iLabs inverted pendulum experiment. Note that the pendulum arm is actually an animation overlaid onto the Webcam image driven by the data being collected. This allows multiple runs of the experiment to be visually compared, assisting in the debugging of the control code.
age of students completing the experiment increased to 30 percent in the fi ve weeks.
The iLab made possible a large increase in the number of experiments performed.
In the traditional two-hour lab, the experiment could only be run a few times because each run has many steps: equilibrating the equipment, running the experiment (several minutes), data analysis, data interpreta- tion, altering the code, and trying the experiment again.
In the iLabs implementation, the experiment execution time remains the same. The effi ciencies gained in having more insight into how to