SOA developer framework for astronomical instrumentation (NICE see Abstract ... applications which are built almost entirely from existing software services. 2.
Astronomical Data Analysis Software and Systems XVII c 2008 ASP Conference Series, Vol. 394, R. W. Argyle, P. S. Bunclark, and J. R. Lewis, eds.
P2.3
A Component Based Astronomical Visualization Tool for Instrument Control and Data Pipeline Florian Briegel, Juergen Berwein and Frank Kittmann Max Planck Institute for Astronomy, 69117 Heidelberg, Germany Abstract. For various instruments developed at the Max-Planck-InstituteHeidelberg there was a need for a highly flexible display and control tool. Many display tools (ximtool, DS9, skycat,..) are available for astronomy, but all this applications are monolitic and can’t be easily enriched by plugins for interaction with the graphical display, and other functionality for remote access and control of the instrument and data pipepline. It was developed on top of Trolltechs Cross-Platform Rich Client Development Framework Qt, the modern middleware Internet Communications Engine (ICE) from ZeroC and the template based SOA developer framework for astronomical instrumentation (NICE see Abstract Juergen Berwein). The display tool is used on the Calar Alto Observatory (Spain) as a guider, for an wide field imager and guider at the Wise Observatory (Israel) and for LBTs interferometer Linc-Nirvana (USA).
1.
Introduction.
Service-oriented Architecture (SOA) is an evolution of distributed computing and modular programming. SOAs build applications out of software services. Services are relatively large, intrinsically unassociated units of functionality, which have no calls to each other embedded in them. The goal of SOA is to allow fairly large chunks of functionality to be strung together to form ad-hoc applications which are built almost entirely from existing software services. 2.
What was done.
The idea for yet another display tool was to build it as a service oriented architecture, to accomplish this goal two things were needed, a good middleware for the services and a graphical toolkit for the user interfaces that fits well into the middleware. After evaluation of different middleware and graphical toolkit packages, it was decided to use Trolltechs Cross-Platform Rich Client Development Framework Qt and the modern middleware Internet Communciations Engine (ICE) from ZeroC. Based on these packages there was a template based SOA developer framework for astronomical instrumentation NICE at the MPIA developed. The next step was to create a collection of reusable Qt Widgets for astronomy. On top of all these packages the astronomical display and control tool b5 was designed and implemented.
323
324
• • • • • 3.
Berwein, Briegel, and Kittmann
The most important “must have” features for the display tool b5 are: Ability to load, save, print and display fits images. Image operations (zoom, pan, manipulate the colormap, set cutlevels,...). Connection managment to instrument services. Plugin interfaces for the graphical display to instrument services. World coordinate system support. How things work.
The basic design concept of b5 is that it has at first only the capability of displaying camera images, it does not need any configuration parameters. Every extra functioniality is supplied by the camera and instrument service application through b5 plugins, which are loaded as shared libraries into b5 (see Figure 2).
Figure 1. Connection Dialog to Instrument / Datapipline. The instrument service can be found by multicast, through a central locater service (manager) or by name, host and port address.
1. After starting the display tool b5, the user can search and select (see Figure 1) the desired server. 2. B5 connects to the Superviser Service (see Figure 2), which tells the user interface what services are provided. 3. The user interface loads the corresponding service widget library into the sidebar(see Figure 1 lower right and left window). 4. Every widget connects to its corresponding service automatically and registers with the service for update data. E.g. the camera widget registers with the camera service, afterwards the camera service pushes image data and status information to display gui. 5. A service widget library can also register for events with the main and overview display area, e.g. the user selects a new window on the main display area, the camera widget sets the window in the camera service as a new readout
A Component Based Tool for Instrument Control and Data Pipeline window or it can draw additional information on the display area, e.g. guiding information, and so on. From the software developer point of view the b5 plugin widgets are using a slice interface e.g. “interface CameraService“(see Table 1) to send commands + parameters to the service, and receiving asynchronously parameters + data through the callback interface e.g. ”interface CameraServiceCallback”. interface CameraServiceCallback extends ServiceCallback { void pushParam (CameraServiceParam param); void pushImage (CameraServiceImage image); void pushMode (CameraServiceMODE mode); }; interface CameraService extends Service { ... void setWindow(Nice::Coord::Rect win, int bin); Nice::Coord::Rect window(); int bin(); void setExposureTime(double sec); double exposureTime(); ... void addCallBack(CameraServiceCallback callback); void addCallBackLocal(CameraServiceCallback callback); }; Table 1.
Simplified camera service interface.
As an example Figure 2 shows an simple camera service application with a camera and fitswriter service. These 2 services services are loosely coupled through the datapipline interface which is a local version of the camera service callback interface (see Table 1). The camera service is using a generic camera driver which hides hardware specific characteristics, as a result the camera service supports various camera hardware without changing the camera service itself. Right now there are services available for telescopes, filterwheels, temperature, pressure, instrument, guiding and datahandling available, which can be combined to service applications and these can be controlled and monitored by the display tool b5 or through scripting. 4.
In the future.
The display tool b5 is a work in progress, after the first successful deployment on the Calar Alto Observatory in Spain as a guider replacement for the 3.5m telescope, and later as an instrument and guiding control tool for the Laiwo wide field imager at the Wise Observatory in Israel, experience has been gained and
325
326
Berwein, Briegel, and Kittmann Camera Server Application
PropertyServiceIf LocatorServiceIf
SupervisorInterface
SupervisorService
CameraInterface
Fitswriter Interface
CameraService
Fitswriter Service
Datapipline
> ComaApplicaticon
Figure 2.
PropertyInterface
PropertyInterface
PropertyInterface
Basic server layout for a simple camera service application.
a couple of additional features were requested. The most important requests for functionality after the first run was: • Mosaic images. • Multiple display scenes. • Guidestar catalog support. Acknowledgements. We thank all our colleagues from the LINC-NIRVANA, Laiwo, and Calar Alto projects at the MPIA, the Calar Alto, the Wise, and the LBT Observatory for their constructive input during the entire development process. References Berwein, J et al. - A template based SOA developer framework for astronomical instrumentation 2007, in ASP Conf. Ser. 394, ADASS XVII, ed. R. W. Argyle, P. S. Bunclark, & J. R. Lewis (San Francisco: ASP), [P9.5] Henning M, & Spruiell M., October 2007, in Distributed Programming with Ice, Rev 3.2.1, http://www.zeroc.com Trolltech Inc., 2007, QT documentation, http://www.trolltech.com/
