The World Wide Laboratory

The control of an electron microscope in our facility has been one facet of a larger project which has been termed The World Wide Laboratory (WWL). The chief goal of this project is to promote the remote control (and automation) of scientific instruments over the Internet. The primary design of the WWL is based on the existence of a WWL Instrument Control Service (WICS) Server.

The WICS Server manages security and device sharing among multiple clients accessing an instrument. The WICS Server communicates with clients using an extension of the HTTP 1.1 protocol. It responds to requests to control an instrument and can send instrument event messages to multiple clients.

The EM Control project can be integrated into the WWL Project in the following manner. A WICS Server is written using the EMC Library (improved performance will likely be gained if it is written accessing the direct instrument control functions at layer 1 instead). This WICS Server will be referred to as an EM Control Server.

A new EM Control Library can then be written that communicates with the EM Control Server (the WICS Server). This allows any application built with this library to control any EM that's has a WICS Server built for it.

Currently the WICS Server is just an idea, it has not yet been implemented for any instrument. However we currently do allow remote control of our instrument. This was done at layer 1. We wrote a server which mimics the serial communications protocol used by our instrument. So communication with the instrument is mediated by this server. Additional features such as a low level instrument response cache are implemented in this server as well as a few functions not built into the instrument's software. One of our next tasks will be to replace this server with a WICS server.

By having an intermediary server between the client and the instrument we do introduce a performance penalty (additional latency). This can be offset by implementing a response cache (at both the server and client end) and by placing many of the automation routines (such as autofocus) on the server itself. This should offset the added latency added by the intermediate server as well as provide many other benefits. These benefits include:

Applications can be run from any platform, not just the one directly connected to your instrument. Your SGI Origin 2000 can be running the instrument from a nearby building for all it matters.

The EMC Server will be multi-user aware. Collaboration is one of the goals of this project for us. This requires simultaneous access to the instrument by multiple users. By funneling all requests through the EM WICS Server the system is able to maintain consistent control over the instrument and manage duplication of requests in an intelligent manner. (i.e. the cache is shared amongst all users)

So there is a big performance win in many situations (caching instrument responses had a large positive impact on our system when I implemented it). When will there be a performance loss? Unknown. The most obvious losses will be in trivial tests, so that makes benchmarking the effects somewhat difficult.

However performance loss may not be critical, as the architecture still allows you to link your application to your device specific EMC library rather than the WICS-based EMC library and you will regain optimal performance (but loose the ability to control the instrument from more than one machine at a time).

Our results so far have been very good. The addition of a semi-intelligent cache on the server has made our applications significantly faster when communicating via the server rather than directly to the instrument. One of the reasons for this is that our EMC Library implementation does not save information about the state of the instrument between calls (since in a shared environment these values could change) which means that each call in the library often has to make several calls to the instrument to perform a function. This is usually done repeatedly as many calls have the same information requirements. By having a cache in the server (each response may have a 1 second cache lifetime) the number of requests to the instrument is greatly reduced.

Page 3 of 54