Toward Standards for Integration of Instruments into Grid Computing Environments D. F. (Rick) McMullen 1, I. M. Atkinson 2, K. Chiu 3, P. Turner 4, K. Huffman 5, R. Quilici 4, M. Wyatt 2 1 Pervasive Technology Labs at Indiana University, USA 2 School of Information Technology, James Cook University, Townsville, Australia 3 Computer Science Department, SUNY Binghamton, USA 4 Department of Chemistry, University of Sydney, Sydney, Australia 5 School of Informatics, Indiana University

Overview Motivations Expected outcomes Requirements Common Instrument Middleware Architecture (CIMA) CIMA application

Motivation Instruments and sensors are critical for advancement in many disciplines –Laboratory instruments –Major shared research facilities –Sensor networks –Field instruments Want to view as real-time data sources and engage in R-T control, not just work with output as files Uniform access methods are needed! –Abstracting a view of the instrument Hardware capabilities Data characteristics –Protocol and transport Standard protocol across all instruments and sensors Multiple field buses

Why middleware for instruments? minimal rewriting of acquisition and processing codes when the underlying instrument and controller are redesigned data fusion across instruments and disciplines is facilitated improved access to national instrument resources by all segments of society improved integration of instruments, computing and storage potential to standardize the instrument-application interface for all types of sensor nets such as roadway management, weather data, cell phone GPS transducers, etc. (cf. IEEE 1451.x)

Requirements Self-describing Functional transparency - what you see is what you get Resource oriented stateful services Interoperable Efficient data transfer –support multiple (hierarchical) fieldbuses and interconnects Lightweight with respect to CPU and memory requirements Support for Intermediate processing on data streams Support for authorization, not just authentication Multiple modes of interaction (read/write, streaming, conditional response) Must be possible to apply to existing instruments and sensors

Components of a middleware for instruments and sensors A means of representing the functions and capabilities of an instrument –Capabilities described in a controlled vocabulary (ontoloy) –Decentralized process for extending capabilities profiles Reusable service architecture –Configured at run-time for specific instruments Layered communication for interacting with an instrument’s functions –Hierarchical interconnects (e.g b->RS-232) Standards used to interpret measured variables –Controlled vocabulary for observables, units, calibration, conversion, etc.

CIMA Components Instrument description Ontology based,Instrument capabilities, access methods, data Static and dynamic information Service architecture Service code Instrument-dependent Plug-ins Life-cycle management Channel/Parcel protocol REST-like high-level protocol in XML Transport neutral, routable, Web Services implementation

CIMA Reference Implementation Applications Synchrotron X-Ray crystallography –Argonne APS ChemMatCARS & UNI/XOR –Lab systems through CrystalGrid (global network of crystallography labs) TOF-MS –Identification of proteins and other macromolecules Robotic telescopes –Remote observing –Queued and interactive operation Sensor networks –Ecological observation (LTER lake buoys, ocean platforms) –Low power wireless sensor network elements

Components - Optics and imaging - Interior and exterior conditions - Positioning - Dome control ObservatoryCIMA service Channel (WS+Parcel protocol) Plug-in D D D D TCP|UDP/IP Instances of Parcel.xsd Instrument Sensor Actuator Top-level CIMA Instrument Model Instrument metadata CCD detector W Weather station X Pointer drive system Y Dome rotate/open controller Z OWL-DL descriptions of the hardware:

CIMA Channel Protocol Built on a simple Web Services interface: One endpoint at instrument, zero or one at client, both are String type SOAP payload is a Parcel XML document or fragment; REST-like protocol using document oriented SOAP messages (Parcels): describe, register, get, set Additional layered specifications can be added as needed, e.g. WS- Security, WS-Addressing … Protocol can be extended by versioning the parcel schema without modification to older clients or instrument services Clients can request data on multiple streams at different rates; One instrument service supports multiple clients

manager.cs.indiana.edu inline T11:31:22Z tiger.cs.indiana.edu Parcel data structure Web Services interfaces are very simple: receive and send Parcel XML docs Parcels are small XML documents that contain: –Header information about the requested operation and reply destination, and –Body containing request parameters, reply detail (actuator status or sensor data information, metadata) Producer-> intermediary-> consumer model needs “routable” structures that intermediaries can forward without completely parsing Suitable for resource constrained wireless sensor networks and source routing protocols Protocol is in the Parcel schema, not in the WSDL so Web Services is not a requirement

WS Interface Channel (Sink) User app main program User application Service main Plug-in Module #1 Sensor Channel (Source) Web Services Interface CIMA instrument service Actuator Plug-in Module #2, etc. (7) Streaming Data (6) Response with Data (3) Request (5) Sensor Data Actuator command … (4) (2) Session token (1) Session Request 1.Session request Parcel with credentials 2.Session token returned to client 3.Request Parcel from client: describe, get, set, register, etc. plus session token 4.Channel calls appropriate plug-in for request type and data source 5.Plug-in retrieves data or runs actuator 6.Response Parcel is returned to client (data or result code) 7.If Client registers for event or streaming data Service calls client periodically or when data is available (timer or event-driven from plug-in) Session token returned to client Session request Parcel with credentials Plug-in retrieves data or runs actuator Response Parcel is returned to client (data or result code) If Client registers for event or streaming data Service calls client periodically or when data is available (timer or event-driven from plug-in) Request Parcel from client: describe, get, set, register, etc. plus session token Channel calls appropriate plug-in for request type and data source

Sensor Intermediary (e.g. filter, event det.) Consumer Register/Request Sensor Data Register/Request Sensor Data’ CIMA in processing pipelines Instrument B Sensor B1 Sensor B2 Instrument A Sensor A1 Sensor A3 Sensor A2 Intermediary A Intermediary B Channel 4 Channel 3 Channel 2 Channel 1 Composite/ Virtual Instrument Channel 5 Channel 6 Creating composite instruments and value-added real-time products with CIMA Consumer

Instrument description and metadata Physical and logical attributes of the hardware and data produced by it Maps sensors and actuators defined in Plug-ins to the semantics of control functions and data outputs of the instrument Applications can query the instrument description to build an operational model of the instrument on the fly Description instance based on ontology, implemented as OWL-DL

Part of the CIMA ontology visualized with IHMC CmapTools

GUI generated automatically from OWL-DL description of a Bruker Smart6000 diffractometer’s goniostat.

Security Line level security through SSL (HTTPS) Additional security available through WS-Security or other SOAP message encryption schemes Access control –Authentication by user-provided credentials and pluggable authN modules to set up sessions (Java/Axis version) –Output filtering by IP address or range (C++/gSoap) –External role-based authorization using SAML and PERMIS (Java/Axis version) –Authentication using institutional infrastructure through Shibboleth (Java or C++) –RBAC appears to be the most appropriate authZ approach, at least from the resource owners’ point of view

Crystallography Application CIMA implementation for single crystal X-Ray crystallography Data from diffractometers are streamed using CIMA to a data management system Current and previous data streams are accessible through a portal using custom portlets

CIMA-enabled Crystallography labs

Lab 2 Instrument 1 CIMA proxy 1 Data Manager Lab 3 Instrument 1 Instrument 2 CIMA proxy 1 CIMA proxy 2 Lab 1 Instrument 1 Instrument 2 CIMA proxy 1 CIMA proxy 2 Data Manager GridSphere Portal Server Grid compute and storage resources OGCE “Grid” portlets Data Manager

Conclusions and future work Some requirements for a middleware for instruments and sensors in a grid computing environment CIMA is an implementation and testbed for working with instruments and sensors as real-time data sources Working on: –Instruments as workflow components –Integration with institutional authentication and authorization systems to support inter-institutional instrument sharing –Automation that leverages the instrument description –Automatic generation of metadata –Registry-based and p2p “semantic” search for appropriate instruments (tiwards a Semantic Web of instruments and sensors) –…

Thanks! Questions? Support for this work provided by the National Science Foundation is gratefully acknowledged. (SCI , DBI ) Thanks also to the CIMA team, developers and users! NSF Middleware Initiative: CIMA project: