| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions! Dokkio, a new product from the PBworks team, integrates and organizes your Drive, Dropbox, Box, Slack and Gmail files. Sign up for free.

View
 

RWSL and RDN Definitions

Page history last edited by ron.evans@nic.bc.ca 7 years, 7 months ago

 

This is the pre-April 2012 Meeting definition page.  To see the new definitions page go to: RWSL and RDN Definitions - 2012-06

-------------------------------------------------------------------------------------------------------------------------------------------------------

Return to How-to Adoption Manual - Home

Return to RDN Scaling

 

 

RWSL and RDN Definitions

 

 

Term Definitions:

 

RWSL:  (Remote Web-based Science Laboratory):  This is a generic software and robotic interface that will allow students to interact with actual lab equipment, collecting authentic real-world data in real-time, remotely over the Internet. (See below for a more complete discussion.)

 

RDN:  (RWSL Distributed Network):  The RDN will be a non-heirachical distributed network composed of various RWSL nodes located at various institutions.  It consists of 2 or more RWSL nodes that are (or may be) distributed among one or more institutions in one or more geographic locations.  This network is what the NANSLO project is initiating with 1 RWSL node in Courtenay and 3 RWSL nodes in Colorado.  (See below for more discussion.)

 

RWSL Node:  This is an RWSL unit that is capable of serving one lab or type of lab at any given time.  These are the building blocks of the RWSL Distributed Network (RDN).  A single institution may house 1 or more RWSL nodes.  However at any given time the institution can serve only as many labs as it has RWSL nodes.  (See below for more discussion.)  An RWSL Node consists of 1 Standard Sub-module and at least 1 RWSL Lab.

 

RWSL Lab:  An RWSL Lab consists of the RWSL Support sub-modules and Lab Equipment sub-modules required to implement one RWSL Lab.  At least one RWSL lab must be available along with a Standard sub-module to serve an RWSL lab to the RDN.  Examples of RWSL labs are the Spectrometer Lab, the Microscope Lab, the Air Track Lab, etc.  Only one RWSL Lab can be "set-up in an RWSL node" at a time.  A single RWSL Lab can be used to support 1 or more lab exercises.  Different lab exercises can be performed using the same RWSL lab by simply preparing different curriculum for each lab exercise.

 

Remote Lab Services (RLS): These are labs served remotely.  In this context they mean RWSL labs that are served remotely.

 

Lab Exercise:  Lab exercises are the activities that students perform using lab equipment.  There is little difference between the lab exercises the student would perform in a traditional face-to-face lab and those they would perform using an RWSL lab except, of course, the RWSL lab is mediated by RWSL and the lab exercise is performed remotely. 

(Note - The term "experiment" is not used here, as most lab exercises that students perform are not true 'experiments'.  An experiment implies that the student has a hand in the design of the activity and that the outcome is not already substantially known before they start.  Very few lab exercises that are performed in undergraduate laboratories (face-to-face or RWSL mediated) are true 'experiments'.)

 

Various RWSL sub-modules: These are the various sub-modules, including hardware and software that are the building blocks of an RWSL node.  (See more complete definitions below.)

 

Production Node vs Development Node

An RWSL "production" node is where the node is configured to serve students.  An RWSL "development" node is when the node is being used to develop more RWSL labs and lab exercises.  The same node can be used for either function but not at the same time.

 

 

Further Discussion:

 

 

Remote Web-based Science Laboratory (RWSL)

 

Concept:

RWSL was conceived to be a generic software and robotic interface that will allow students to interact with actual lab equipment, collecting authentic real-world data in real-time, remotely over the Internet.  The original concept called for the ability to place any lab equipment into the RWSL unit.  This would result in one lab being run for a period while students from a particular class collect the data required to complete their lab exercise and ultimately their lab report.  While the concept has now evolved somewhat it retains this basic idea.  We are now envisioning an RWSL distributed network made up of RWSL Nodes, each of which is designed to serve a particular type of lab exercise with 1 or more lab exercises possible from each node.  Multiple RWSL Nodes can exist at 1 specific location or be distributed over multiple locations/institutions thus allowing the RWSL resources and expenses to be shared over a much wider community of institutions.  There is currently 1 RWSL Node at North Island College (NIC) in Courtenay on Vancouver Island and we are building 3 more at CCCS in Colorado.  The larger project after the current project is completed would see additional RWSL nodes built at other locations/institutions both in BC (and Canada) and in the WICHE region of the US and beyond.

 

RWSL Node:

One RWSL Node consists of:

1 RWSL Standard Sub-module (required) {Should this be called an "RWSL Base" instead?}

1 or more labs that can be served to the NANSLO RDN

 

Each RWSL Lab consists of:

0 or more RWSL Support Sub-modules

1 or more Lab Equipment Sub-modules

 

For further definition of RWSL labs and sub-modules go to this list of existing RWSL sub-modules.

 

 

Minimum Infrastructure Required to Establish an RWSL node (Also see RWSL Node Requirements):

  1. Minimum Power requirements
  2. Minimum Bandwidth Requirements
  3. Minimum Physical Space and lighting
  4. etc

Albert and Dan, I will need some input from you on this section!

 

 

Each RWSL Node can run 1 laboratory exercise at a time and may be controlled by one student from a lab group at a time.

 

See the document RWSL sub-modules for a list of various RWSL sub-modules currently developed (or being developed).  This document shows which modules are required for various RWSL mediated lab exercises.  Note that there is overlap, but in many cases through careful scheduling we should not need to purchase more than one each of the RWSL Support Sub-modules or the Lab-equipment Sub-modules (there will probably be a few exceptions, but these have not been identified yet).  However, every RWSL Node requires one RWSL Standard sub-module!

Note - While it isn't essential to purchase more than one set of sub-modules for each RWSL Lab, dependability will require that key pieces of equipment should be duplicated so that there is some contingency in place for unexpected equipment failure.

 

RWSL Distributed Network (RDN)

The RDN is a non-heirachical distributed network composed of various RWSL nodes located at various institutions.  We are currently envisioning a network that will be distributed over multiple institutions at a variety of geographic sites.  Institutions will be able to participate at a variety of levels, from simply accessing the existing NANSLO RDN to obtain Remote Laboratory Services (RLS) for their students, through levels where the institution will serve some RLS to the NANSLO RDN while obtaining other RLS for their student for those labs they don't serve themselves, to institutions that are primary RLS providers for their own as well as other NANSLO RDN member institution students.  An additional level of participation will be institutions that will provide RWSL Development Node capabilities to the entire NANSLO RDN.

 

 

NANSLO RDN Serving Institutions (or just "Serving Institutions") (These are Tier 4 Institutions): 

These are institutions (schools, colleges, universities, etc) who host an RWSL node that serves remote lab services to the NANSLO RDN at some minimum level (to be established by the NANSLO Board).  Serving Institutions can supply representatives to all NANSLO RDN governance bodies and functions.

 

NANSLO RDN Participating Institutions (or just "Participating Institutions") (These are Tier 3 and 4 institutions): 

These are institutions (schools, colleges, universities, etc) who consume or serve remote lab services via the NANSLO RDN.  Participating institutions that are not Serving institutions will have representation on the Discipline panels.

 

NANSLO RDN Interested Institutions (or just "Interested Institutions") (These are Tier 2 institutions): 

These are institutions (schools, colleges, universities, etc) who consume or serve 'small' amounts of remote lab services via the NANSLO RDN.  The NB will establish the number of students involved below which, it is considered a 'small' amount.

 

 

 

NANSLO RDN Services and Advantages

(This section will help to answer the question, "What advantage does an institution accrue by joining the NANSLO RDN?  Why would they want to join?)

 

 

 

 

Document End

---------------------------------------------------------------------------------------------------

Input: Everyone, please insert anything you think I should include or any pertinent comments in the comments at the bottom of this document.  I will incorporate them into this section when I write it.  Thanks!

-----------------------------------------------------------------------------------------------------

 

 

Some Notes <These are not necessarily part of this particular document, but I didn't want to lose them so they are temporarily here>:

 

> Calculating RWSL Capacity:  <This should be addressed in the scheduling document.>

The Excel document, “RWSL Capacity Estimator 110715” is a simplistic attempt to estimate the number of students who can use an RWSL Node in one year.  There are extenuating circumstances that could drastically affect the results this spreadsheet predicts.  However it is our best attempt to date to get at this number.  You can see how the various assumptions can affect the total student-courses that can be offered each year, but further refinement is encouraged. 

 

In the first section you enter your assumptions (# of weeks/semester, # of lab students in a lab group, # of days RWSL will be down for maintenance/week, etc).  Then the estimator gives an idealized number of students who will be able to use that number of RWSL Nodes in one year.

 

> Production vs Development:   <This should be addressed in the scheduling document.> An RWSL Node can be used to serve students (a production node) OR it can be used to develop additional RWSL lab delivery options (a development node), but these 2 uses are mutually exclusive at any given time.  As we are still in the development stage, I encourage you to think in terms of either scheduling significant blocks of time for development on one node, or dedicating one RWSL Node for further development of the RWSL lab exercise repertoire.  Ideally if you want 3 lab exercises to be delivered to students simultaneously then there should be 4 RWSL Nodes so additional development can continue.  The 4th node can also give you have some back-up in case one of the production nodes goes down for a period of time.  Obviously this may not be financially viable during this 15 month project, but it will be essential in the follow-on project if it is funded.  Further the RWSL Node at NIC has thus far been primarily used for development work, with only minimal student use.  If it is converted to a production node then development work will have to cease while students are using it.

 

> A Note on RWSL Lab Exercises that should and should NOT be developed for RWSL Delivery:  <These distinctions are important not to lose, but they don't belong in this document dedicated to RWSL Development Nodes>

While the original concept called for ANY lab equipment to be able to be set up within an RWSL node, practicality of cost and potential hazard to students and their families gives us a rule of thumb that dictates which lab exercises should be set up within an RWSL node and which should be delivered by another strategy (we have chosen student purchased lab kits primarily for these other delivery methods).  Labs that should be developed for RWSL are those labs that are moderately expensive (to very expensive) or potentially hazardous to students or their families should be developed for RWSL delivery.  Those labs that are inexpensive and that pose low risk to the student or their family should NOT be developed for RWSL delivery.  As we proceed we may want to further clarify this rule. 

 

An example of a lab that should most likely NOT be developed for RWSL delivery would be dissection labs in biology.  One of our first thoughts was that we could get the robotic arm to perform dissections under student control.  This would have been “cool”, but upon further discussion we realized that dissection kits are very cheap and with a little care on the part of the student they do not pose any more risk to themselves or their family than a set of kitchen knives would.  Hence these lab exercises should be delivered through a lab kit giving the student actual hands on experience.  Besides, the student is much more capable of performing this kind of activity that the robotic arm is ever going to be in the foreseeable future.

 

An example of a lab exercise that should be developed for RWSL delivery (and we did this) is the air track labs.  While not particularly hazardous, air tracks are moderately expensive and would drive the cost of the student lab kit out of the reach of the vast majority of students.  We thus developed several lab exercises that use an air track under the control of the RWSL interface.

 

 

 

Original Document: RWSL Definition 1108

 

 

Comments (9)

ron.evans@nic.bc.ca said

at 1:39 pm on Apr 4, 2012

Hi Catherine, I've started fleshing htis out based on feedback from Dan. Please see the RWSL Node Requirements page:
https://nanslo.pbworks.com/w/page/47284100/RWSL%20Node%20Requirements
Ron

Catherine Weldon said

at 11:31 am on Apr 3, 2012

Ron, thanks for clarifying the above list to add/subtract per requirements.

Catherine Weldon said

at 11:30 am on Apr 3, 2012

NANSLO RDN Services and Advantages

I'll start fleshing this out soon.

Catherine Weldon said

at 11:25 am on Apr 3, 2012

RON: I'M TRACKING DOWN THIS INFORMATION ALONG WITH THE COST OF SUCH AT CCCS. Do these added points in CAPS seem right to you? anything else we should be asking of?

Minimum Infrastructure Required to Establish an RWSL node:
AND ASSOCIATED COSTS AT CCCS (NOT NECESSARILY FOR THE FINAL REPORT, BUT USEFUL TO DISCUSSION OF FINANCIAL MODELS)

Minimum Power requirements PER SUB-MODULE CPU?
Minimum Bandwidth Requirements PER SUB-MODULE CPU?
Minimum Physical Space PER SUB-MODULE (MULTIPLY BY NUMBER OF DESIRED SUB-MODULES TO GET TOTAL PHYSICAL SPACE)
UTILITY COST OF NANSLO PHYSICAL SPACE AND INDIRECT USE OF IT FACILITIES AT CCCS
STAFFING (PORTION OF IT STAFF INDIRECTLY ASSISTING LAB TECHNICIANS)
NANSLO TECHNICAL STAFF
CCCS TECHNICAL SERVICES (AUTOMATIC BACKUPS, VIRUS SCANS, SECURITY, ETC)
COSTS CONTRIBUTED BY CCCS NOT CONSIDERED IN NANSLO BUDGET SUCH AS ROUTER, CABLES, EXTRA EQUIPMENT THAT WAS UTILIZED IN SETTING UP AND MAINTAINING THE LAB

ron.evans@nic.bc.ca said

at 4:36 pm on Feb 22, 2012

Pat said: Regarding the dissection example, we may want to modify that language to it not being a high priority for now because that may change as increasingly surgery is performed by robotics.:

I'm open to suggestions, but I don't see the problem. The main reason for using that example is because dissection exercises in first year science labs are cheap and safe (as long as students respect the scalpels, don't cut themselves, and keep them out of reach of small children). There seems to be no point in spending huge amounts of money to make this first year dissection exercise doable on-line when the samples and dissection kits can be sold in a lab kit for relatively small amounts of money. Students should be able to afford to purchase this. Surgery is another story and well beyond the scope of our current focus with RWSL. If we begin training surgeons one day then their lab exercises will be neither cheap nor safe (particularly if the subjects are still alive), so then developing an RWSL lab to do this is probably warranted, but I think others have probably already done this. ;-)

The main point is that if students could satisfactorily perform a lab exercise with samples and equipment that are readily available or cheap and safe there seems little reason spend large amounts of money to develop RWSL labs to let them do these exercises, but if the lab materials are even moderately expensive (so that students can't purchase them in a lab kit) of potentially dangerous to the students or their family, then we should consider developing RWSL labs to serve them on-line.

Ron

ron.evans@nic.bc.ca said

at 4:19 pm on Feb 22, 2012

Hi Pat, Sorry I didn't respond sooner, I just didn't scroll down this far and missed your comments when you made them. I won't make that mistake again.

We have always defined RWSL as a "generic software and robotic interface". It is an interface because it sits between the student and the lab equipment and mediates their access and interaction with that equipment. It is generic because any lab equipment can be set up within it and students can come to the same site to do their various labs depending on what is scheduled at that time. How is it any more than that? The lab equipment is what they would go to a face-to-face (f2f) lab to use so the lab equipment is not RWSL. The fact that it is configured within RWSL means they have access to it via the Internet and don't have to attend a f2f lab. RWSL uses software and robotics to accomplish its mediation. RWSL is more a concept than specific pieces of hardware and software. I'm sure it could implemented in other ways than Albert has chosen to implement it. In a sense you could call the MIT iLab shared architecture is an RWSL implementation although I'm sure they would object since they predated us. ;-) RWSL is basically the idea that students no longer need to attend a f2f lab to accomplish their lab exercises, we can enable them to do this on-line.

We conceived RWSL in an educational context so we are calling our users students ... granted this same technology can be used in many ways by many people who aren't necessarily students, but do we want to evolve outside the educational realm? I'm willing to consider calling them users, but I'll need to be convinced that it is appropriate. We are primarily targeting students, so I'm not sure the change is warranted.

Does that help?

Ron

ron.evans@nic.bc.ca said

at 3:44 pm on Feb 22, 2012

Ron -- Yes the node definition has evolved somewhat since we first used it, but the old usage obscured the fact that with a single Standard sub-module only one lab at a time can be served to the RDN. So it became clear that CCCS has 3 nodes, because they have the equivalent of 3 standard sub-modules while NIC has only 1 node because we have only one standard sub-module. So it seemed more appropriate that one RWSL Node implies the ability to serve one lab exercise at any given time to the RDN. If you want it to mean 1 institution then we lose this clarity. Wouldn't it be better to just call institutions institutions and the extent that they can serve lab exercises to the network be indicated by the number of nodes they host?

The term RWSL Lab has emerged as I've been writing about things. (I haven't defined it yet, but will do so soon.) Originally the RWSL support sub-modules and the lab equipment sub-modules were conceived to be at almost the same level as the Standard sub-module, but in writing the RWSL Sub-Module document to clarify those definitions it has become clear to me that they are not. While 1 Standard sub-module is required to serve any lab to the RDN various combinations of the support and lab sub-modules are required for each RWSL lab. So here is what I am envisioning now:

RDN consists of institutions each hosting one or more RWSL nodes to the RDN. These RWSL nodes are each on the network at an equal level and consist of 1 Standard sub-module and and one RWSL Lab. Each RWSL Lab consists of the support sub-modules and lab sub-modules required to serve that particular lab. Hence we can talk about the RWSL Spectrometer Lab or the RWSL Air Track Lab or the RWSL Microscope lab. Now lab exercises are what the student performs on each of these RWSL labs and there can be 1 or many lab exercises defined for each RWSL lab.

Does that make sense?

Pat Shea said

at 3:24 pm on Feb 10, 2012

Probably should add definition for lab experiment.

Pat Shea said

at 3:23 pm on Feb 10, 2012

Pat---I am a bit confused by the definition of node. In the proposal I think we used that term to define a laboratory or laboratories under the jurisdiction of one entity.---e.g, the NIC node and the CCCS node. It seems like nodes on a network is at a higher level than nodes in a laboratory as defined here if I understand correctly. Also I think RWSL is more than generic(?) software and an interface because equipment must be specifically configured. In addition it can be used by more than students so perhaps we should use term user. Regarding the dissection example, we may want to modify that language to it not being a high priority for now because that may change as increasingly surgery is performed by robotics.

You don't have permission to comment on this page.