Yohannes and the Labnetwork Mailing List:
As Vicky Diadiuk from MIT has indicated, Stanford University, UC Berkeley, and
MIT have been jointly developing a software package named Coral that we hope
will be useful in helping to manage university semiconductor research
laboratories.
Bill Murray here at Stanford has been the primary architect of this system
and has also provided the lion's share of the software development activity
to date. If there are errors in what I say here, I'm sure that Bill will
correct me ... and you should definitely accept his answers as being more
knowledgeable than mine. Nonetheless, I'll do my best to give you an overview
of what Coral is, what it does, what underlying support it requires, etc.
Briefly stated, Coral currently provides the cabability of reserving equipment
within a semiconductor research laboratory, enabling/disabling it before/after
use (for usage and accounting records and for insuring that a person is
authorized to use that equipment), reporting problem and shutdown conditions
on equipment when they are in need of repair, and for prviding a means for
staff members to record time spent training lab members or processing wafers
for them (either for the purposes of effort reporting or recharging for their
time). We believe that these are the essential elements that are required to
help manage and operate laboratories of this type. Clearly there are a number
of other capabilities that would be nice to have. For example, inventory
tracking for supplies used or recharged in such labs, a means of assembling a
process library and building runsheets, and facility monitoring would all be
nice to have. We hope and expect that future releases will begin to include
some of these features.
The software package that constitutes the Coral system makes use of a number
of features and standards that, we hope, will make it sufficiently flexible to
operate in a number university environments. These features include:
1. This system is currently written almost exclusively in Java which, we
believe, will make it possible to run on a wide variety of platforms without
extensive porting activity.
2. It is a distributed set of clients and servers that offer great flexibility
in configuring which portions run on which hardware, etc. The distributed
communications between various clients and servers are based on the OMG
(Object Management Group) CORBA (Common Object Request Broker Architecture)
standards which are supported by many hardware platforms and network
configurations.
3. The behavior of each client and server is specified by an IDL (Interface
Definition Language) functional definition. This makes it possible to add
additional modules and functionality in a seamless way.
4. Database communications rely on the JDBC (Java Database Connectivity)
standards. Accordingly, the Coral system should ride on a wide variety of
underlying databases including Oracle, Informix, Postgres, Ingres, and MySQL.
Cautionary note: This is not yet "shrink wrap" software ... double clicking on
an icon won't install it, selecting the "Preferences" menu won't configure it,
etc.
Where do we stand in this development?
Stanford has been running the Coral system as our primary laboratory
management software system (that is, "in production") since January, 2000.
MIT, UC Berkeley, and, most recently, Penn State are in various stages of
bringing this system up in their laboratories ... but I don't believe that any
of them are yet fully operational. In other words, we are still fairly early
in the process of learning how to better distribute this to other schools and
in terms of making sure that the system is easily configurable so as to
accommodate different configurations and "business rules" at different sites.
It is still a system under development. Bill Murray ... our principal
developer ... is doing a "clean up" of some of the underlying tables in the
database and we are working on a new resource client/server that will make it
easier to add new lab members, set up valid projects/accounts to which they
can charge, etc. We are hopeful that those changes will be completed by May 1
(or so) ...
What hardware/OS platforms do we use? As I indicated, because this is a Java
application, our clients and servers should run on about any hardware platform
that supports Java 2. That should include, at the very least, all Windows
variants, Solaris, and Linux. As near as we can tell, Apple seems to be sadly
behind the field in terms of Java support, so Macs may not be included in our
list. That said, all development has been done under Solaris 2.6 on Sparc
architecture. Additionally, we have a private network of about 25-30 Sunray
"network appliances" that are the machines upon which Coral runs in our lab.
One of the big bonuses of using the Sunrays in the lab is that they all have
Smart Card readers. When someone enters our lab, they grab a (random) Smart
Card from a box at the entrance to our lab. When they log in, their "session"
is tied to that Smart Card. In effect, this means that their session "follows
them" throughout the lab. It also means that someone can be composing a
lengthy e-mail message (such as this one ...), and someone can come up to
enable a piece of equipment on "my" Sunray. I pull out my Smart Card, they
insert theirs (which immediately restores their session), they enable a piece
of equipment and pull out their Smart Card, I re-insert mine and am back
exactly where I was.
Realted to equipment enabling and disabling, hardware can be enabled/disabled
on the Coral system using the honor system ... that you probably already use
if you rely on paper sign up sheets.
Alternatively, we have a custom ISA board (that runs in a Linux machine) that
interfaces to a set of magnetically-latched relays that are typically placed
in series with other interlocks found in many pieces of equipment. This makes
it possible for a piece of equipment to not run properly unless it is enabled.
For example, if a piece of equipment has an interlock on cooling water and the
enable/disable magnetically latched relay is in series with it, a piece of
equipment that has not been enabled would appear (to the machine) to have a
cooling water fault.
If you are interested in more details of the Coral software system, I can
provide a couple of options:
1. I have a Word document that includes screen dumps that shows what it looks
like, and what it can do from the persective of someone in the lab. This is
basically our user guide. If you send me e-mail (shott@snf.stanford.edu), I'd
be happy to send you a copy of this document.
2. For a select subset of people ... such as the lab manager of a facility at
another university ... I can set you up as a "Demo User" on our system and let
you deploy our version of Remote Coral. This will actually download the Coral
client application onto your machine and allow you to access our "live" system
to take it for a test drive. Because our servers have to update all clients
everytime anybody makes/deletes a reservation, enables/disables equipment,
etc. we have to be careful not to deploy too many of these test versions of
Remote Coral for fear that it will slow down our response time for folks in
the lab.
I apologize for the length of this message, but thought that it would be
useful to provide a reasonably comprehensive overview summary of Coral.
Thanks for your interest,
John
This archive was generated by hypermail 2b29 : Tue Mar 09 2004 - 07:49:04 EST