APM Welcome, APM North West Network Conference, Synergies Across Sectors
Online Laboratories: Bringing the Lab to You Anywhere
1. ONLINE LABORATORIES:
WE BRING THE LAB TO YOU
Mark Schulz
Centre for Educational Innovation & Technology
The University of Queensland
http://ceit.uq.edu.au
m.schulz@uq.edu.au
2. “If You Can’t Come to the Lab…
the Lab Will Come to You!”
Jesús del Alamo – MIT, Professor Department of EECS
(Earth at 89 GHz; courtesy of J. Grahn, Chalmers U.)
8. REQUIREMENTS
• Experiment must (be able to) be computerised
• Must have access to the Internet
• Minimal software requirement at the user end
• Minimal use of consumables
9. WHY USE A
REMOTE LABORATORY?
• Time Accessibility • Physical Accessibility
• Resource Accessibility • OH&S Issues
• Location Accessibility • Scalability
10. WHEN NOT TO USE A
REMOTE LABORATORY?
• To replace laboratory experiments
• Cheap, commonly available equipment
• Replaceable consumables requiring human intervention
• Continuous human intervention required
• Experiment requires proximity and haptic interface
• Experiment can’t be computerised
11. HOW TO FIND AN
EXPERIMENT
http://openilabs.ilab.uq.edu.au/
19. iLab Batched Architecture
Lab Server
Campus
network Internet
Lab Server
Client Service Broker
University #1 Databases
University #2 Databases
20. WHAT DOES ILAB PROVIDE?
• SERVICE BROKER (web services):
• user and access management (single sign-on coming)
• local (institutional) management of data storage
• scheduler/booking system for access management
• LAB SERVER:
• access given to each Service Broker
• focus on running experiments
21. iLab Batched Architecture
• Special purpose system specific to an
experiment
• Developed by domain specialist
• No user management here
• Verifies experiment before execution
Campus
network Internet
Lab Server
Client Service Broker
University Databases
22. iLab Batched Architecture
• GUI to lab
• Embodies pedagogical experience
• Developed by domain specialist
• Contains generic modules that are
recycled: i.e. graphing, collaboration
Campus
network Internet
Lab Server
Client Service Broker
University Databases
23. iLab Batched Architecture
Campus
network Internet
Lab Server
Client Service Broker
• Serves client to student’s computer
• Mediates between Client and Lab Server
• Performs generic functions: user management,
data storage
• Single signon access to many labs
University Databases
• Managed by and located at end user University
24. iLab Architecture:
development responsibilities
Lab provider:
+ develops Lab Server
Lab provider: + can customise modules developed at UQ
• develops Lab Client + registers this with the Service Broker
• registers this with Service Brokers
Campus
network Internet
Lab Server
Client Service Broker
• provides generic functionality
• developed by MIT, open source
• has well defined web services interfaces
University Databases
25. Lab provider:
• manages Lab Server
• sets lab policy
• manages groups, not individual users
iLab Architecture:
management responsibilities
Campus
network Internet
Lab Server
Client Service Broker
End-user institution:
• manages Service Broker
• manages users (registration, authentication)
University Databases responsible for user data (storage, archiving)
•
26. iLabs Use Around the World
Chalmers
NWU Pavia
Deusto Carinthia
Portland
MIT Parma NTU DLUT
CMU AUB
Cairo CCU Taipei
ITESM
OAU Makerere
UDSM NUS
Mauritius
Queensland
RMIT
iLabs has been used by
22 universities on five continents.
Physical = proximate access to physical equipment and materials; may even be computerised; still essential for training students\nOnline = access via a network (web in our case); must be computerised\nVirtual = simulated; run a simulation or perform in a simulated space (eg, Second Life).\nRemote = accessing a physical lab via the internet\n
Focus of this talk, as this is what we do in CEIT.\nBATCH: set up parameters, send to experiment, wait for a turn to run experiment, results sent back.\nExample: read the radiation count of a radioactive sample for a fixed time at three different distances from the source. \nNO NEED FOR PHYSICAL PROXIMITY; ACTIVITY is PROGRAMMABLE SET OF STEPS\nINTERACTIVE: Book a slot to run an experiment, have complete control of inputs over that time (just like a real expt.).\nExample: download a program into an instrumented embedded computer system and interact with the physical interfaces.\nNO NEED FOR PHYSICAL PROXIMITY, BUT MUST RESPOND TO A SEQUENCE OF INPUTS; difficult to fit to BATCH model.\n
\n
\n
\n
Access: uses port 80 for all communication. Interactive may require other ports (e.g., LabView)\nMinimal Software: download time for UI - mention Africa. Aim is no local Installation of software\nMinimal need for humans at experiment end (fluid replacement, MIT Reactor and human to open port).\n
Time: scheduled classes rarely exceed 9-5 limitations; 24/7 access is the aim. Time to tinker!\nResource: limited set of equipment, places difficulty on access at relevant time in the course. Cost limits provision here too.\nLocation: USQ telescope accessed from US in their daytime teaching time slot, and v.v.\nPhysical: MIT neutron beam port is inside reactor; hard for Australian students to attend on regular basis. \nOH&S: no high school student in QLD can do a school based radiation experiment due to lack of on-site certified radiation officer and facilities.\nScalability: Handle large numbers of users in a manageable fashion.\n\n
Replace: Meant to supplement use of lab\nCheap: measure the potential drop across a resistor with a multimeter (NOT the case in Africa though).\nconsumables: chemicals that are consumed during the experiment; new ones needed and disposal of used ones.\nPointless to pay someone to set up each experiment manually, then turn over control. Won’t scale.\nHaptics: If touching real knobs is part of the learning objective, then must be there. Exploding electrolytics story here.\nMust be able to computerized and be intelligible after this process. Some biological processes may not fit this,e.g., dissect a frog.\n
\n
2nd time of day - use of farms of experiments\nAccess to experiments at MIT.\nlast entry - Flex client is a copy of NWU iLabCentral client to save bandwidth\n
Searchable repository of experiments - not just iLab\nUses semantic web technologies\nAllows more precise searching\n