From Intrument Element Wiki

Jump to: navigation, search



The Tiny Instrument Element is a piece of skeleton software that makes it easy to expose the functioning of a generic instrument via a Web Service interface.

custom paper


The term "tiny" refers not to the kind of instrument, but rather to the software implementation. The design is kept simple and intuitive, but hopefully not minimal. From a general point of view, one or more instruments can be controlled using an object that implements the Parameter Listener interface. These objects present new events to the Control Manager using the instrument Functionality interface. External components, like a control room or a workflow engine, can access the controlled instrument(s) in a service-oriented way using a Web Service that retrieves the requested information via the instrument control interface. Depending on the equipment controlled, the control manager can be a complex set of objects that perform fault tolerant or autonomic functionality, or, if only one instrument is controlled, the control manager can just act as a proxy for the information contained in the device. The project structure of the application follows the typical Maven format, and an instrument is integrated by implementing two interfaces. Instruments can work in a synchronous or asynchronous way, and they can be stateful or stateless. Everything is hidden behind the interfaces mentioned above. The JavaDoc provides a detailed description of each package and class. For additional details, refer to the project homepage.

A Uniform Instrument Model

Since the instruments are heterogeneous in nature, one current shortcoming is that the applications that use them must have a complete operational model of the instruments and sensors they work with. This makes maintaining investments in these codes difficult and expensive when the underlying instrument hardware is changed and/or improved. A primary design goal for this section is to externalise the instrument description so that applications can build an operational model ‘on the fly’. This approach makes it possible to preserve investments in software as instrument hardware evolves and to allow the same code to be used with several similar types of instruments. The APIs can be divided in 4 different area dealing with different aspects:

  • Accessing a Single Instrument
  • Accessing Multiple Instruments
  • Interfacing Instruments and Computational Infrastructure
  • Providing Authentication and Authorization

Abstracting A Single Instrument

Instrument Model in complex scenarios
Instrument Model in complex scenarios

We can consider a generic device as a collection of parameters, attributes and a control model, plus an optional description language. The more detailed parameters are variables on which the instrument depends, like range or precision values of a measure, while attributes refer to the effective object that the instrument is measuring.

The main difference between parameters and attributes is that typically the first are accessed in a polling mode, while for certain types of attributes, like a cam streaming, a publish/subscribe or a stream access method is more appropriate. Therefore, both push and pull access ways must be supported for attributes. The control model represents the list of commands that the instrument can support. This list can be expressed using a state machine model, a Petri Net, etc. We have to note that in this abstraction, the term ‘command’ refers to both the actions that change the instrument status and those that do not. Parameters, attributes and the control model can give the possibility of controlling every possible instrument or sensor, but what is still lacking is the possibility to allow the device to describe itself, giving the user the possibility to understand what exactly it can do with this instrument. In order to achieve this goal, an XML-based description language is also part of our instrument abstraction.

Languages like the SensorML or OWL-DL can be use to describe the semantics of the particular instrument. The presented abstraction provides a uniform layer across different devices and can be used as a building block for the control of complex systems In order to simplify the control of these systems, instruments can be logically (or physically) grouped into hierarchies, from which data can be aggregated or for which control commands affect multiple sensors or actuators. What is needed in this case is an instrument aggregation model, like the one that we will present in the next section, which is capable of controlling all these devices in a congruent way. The class instrument control and the control manager implements this abstraction.

Multiple Instrument Aggregation and Organization

In scenario like Sensor Networks or complex control systems different instruments need to interoperate with each other in order to achieve common goals. In order to simplify the access to these devices we still would like to provide to external users a single entry point.

Instrument Model
Instrument Model

In this situations one or more Control Managers control different resources and they may be organized in different topologies. Therefore the Web APIs that the IE is providing must provide access to multiple devices and to a index that contain an identification of all the available resources and optionally a small description.

Link with a Computational Infrastructure

From the Web APIs is also possible to instruct instrument to contact the computational infrastructure for running complex data processing and leverage the available distributed storage facilities. This way, the data produced by the sensor equipment may be directly and continuously stored in a distributed storage system, making it possible to submit analysis jobs as new data arrives.

Authorization and Authentication

Some Equipment can be shared among organizations and people so the Web APIs supports access control to these devices that require it.


Instrument Model
Instrument Model

To summarize instruments are included in the Web as a service-oriented API, providing the following operations:

  • Monitor and control of one or more instruments
  • Access and retrieve an instrument configuration parameters and topology.
  • Collect the current measurements performed by the instrument
  • Provide a set of APIs for the integration between instrument and Computational Infrastructure.

The API presented in the figure below exposes a subset of the design elements introduced in the previous section. The APIs take into account that more that an Instrument Element may contain more than one Instrument Manager and that IMs may be organized in certain topologies. Therefore graph navigation APIs have been provided like getInstrumentManager() and getInstrumentManagerInContext(). The Access to the computational infrastructure is provided by a wrapper around the Computational Infrastructure User Interface. Therefore the produced data can then be moved to a storage element using familiar commands sent to the instrument service via the executeGridUI() method or simplified methods like moveFile() or submitjob().

Additional Resources

External Resources

  • Francesco Lelli, Eric Frizziero, Michele Gulmini, Gaetano Maron, Salvatore Orlando, Andrea Petrucci and Silvano Squizzato. The many faces of the integration of instruments and the grid. International Journal of Web and Grid Services 2007 - Vol. 3, No.3 pp. 239 – 266 Electronic Edition
Personal tools