Figure 1: ASC Layered Architecture.
Figure 1: PS 5 Kb
Next: Object-Oriented Modeling and Design for Sloan Digital Sky Survey Retained Data
Previous: NICMOS Calibration Pipeline---A Collaborative Project Between IDT and STScI
Table of Contents --- Search ---
PS reprint
M. Conroy, S. Doe, J. Herrero
SAO/ASC, 60 Garden St., Cambridge, MA 02138
The ASC design challenge is to balance the requirements of developing an Open Environment while integrating software from existing systems and diverse environments. The ASC has these further design requirements: flexibility, extensibility and economy. Flexibility allows the software to meet all needs of users and processing scenarios. Extensibility allows the ASC system to fulfill functions beyond those currently required and allows users the ability to customize, extend and adapt the ASC functions. Economy allows the system to be developed in a cost-effective way in this era of shrinking NASA budgets.
The ASC design must derive as much benefit as possible from previous systems, while evolving toward a next generation system with improved functionality. This motivates the design requirements of: maximum software reuse, compatibility and maintainability. Software re-use achieves savings in money, development time, verification effort and maintenance costs. Software compatibility allows the ASC calibration system to easily ingest both the data and software that is delivered by the AXAF instrument teams. For flight, the ASC must provide algorithms used by other projects to support multi-mission and multi-wavelength analysis.
The ASC system must provide multiple analysis interfaces that support various levels of interactive use as well as automated batch processing. The ASC tool set must be invokable from both simple command-line character-based interfaces as well as GUI-based interfaces. This same ASC tool set must run both interactively and from batch scripts such as automated pipeline processing.
A layered architecture provides the solution to the disparate ASC design goals discussed above. An Open Analysis Environment is achieved by isolating system components into layers and developing additional thin layers to provide a common Application Programming Interface (API) between the layers as illustrated in Figure 1.
Figure 1: ASC Layered Architecture.
Figure 1: PS 5 Kb
The SAO IRAF compatible parameter interface provides a common parameter interface to all tasks. It can be used both from UNIX shell scripts and from host programs. All tools used by the ASC will conform to this parameter interface standard which exactly emulates the highly successful and widely-used IRAF parameter interface. The interface supports both 3GL and 4GL interfaces.
The ASC tool set must be able to read and write a variety of common astronomical data formats, organized in a variety of ways, thus reducing the need for file translations. The Dynamic Data Format (DDF) abstraction will provide support for multiple physical storage formats. Additional libraries in the data manipulation layer will provide every tool with a built-in stacking interface and a built-in selection mechanism (Conroy et al. 1995). The Application Programming Interface (API) will use an abstract data model to define the access mechanisms to the data (Van Stone, Conroy, & McDowell 1996). The stacking mechanism allows all the tools to accept a list of input files. The filtering mechanism allows all the tools to accept a selection description to define a slice of the data.
The translation wrappers will consist of additional language bindings for all data analysis libraries. The ASC software will be developed in C, but Fortran bindings to these C libraries will be provided. This allows developers a choice of implementation language that is independent of the language chosen for the library development. The adaptation wrappers allow multiple options for the environment I/O library choice. Adaptation wrappers can be written for each supported environment. In this way, software from disparate analysis environments, such as IRAF or IDL, can be adapted to work in the ASC environment.
The data manipulation libraries will be built upon the ASC Data Model and the DDF libraries to provide high-level data manipulation capabilities. The computational libraries will be built to isolate the algorithms from the data manipulation routines. This allows the algorithm libraries to be imported from many sources, provides compatibility with existing analysis packages and maximizes the re-use of software.
The ASC Open Architecture allows construction of a customized data analysis system with a standard interface from existing tools, ASC developed tools and user-developed tools as illustrated in Figure 2.
Figure 2: ASC Open Architecture.
Figure 2: PS 4 Kb
Existing tools will be imported into the ASC data system untouched and provided with a thin Korn-shell wrapper to adapt the tool to the standard ASC-defined tool interface. These wrappers provide a standard UNIX shell interface to all tools independent of the tool's native environment and parameter interface. In particular, these Korn-shell scripts allow the existing IRAF tasks to be run outside of the IRAF CL, but with the familiar parameter interface.
The ASC developed tools will depend on features of the Open-IRAF system to provide the required design features: C-bindings for Open-IRAF libraries, host-interface for Open-IRAF libraries and FITS kernels for IRAF data formats. The C-bindings for existing IRAF libraries allow new IRAF software to be developed in C. The IRAF system provides tested, maintainable, portable software libraries, as well as portable, platform independent build utilities. The Host-Interface IRAF library allows UNIX programs direct access to IRAF-supported data formats, without the need for format conversions. UNIX tasks can be built to integrate IRAF libraries with other commercial and network libraries. This also allows network clients to access IRAF data structures directly. FITS image files will be accessible directly via the IRAF IMIO library interface and FITS table files will be accessible via the STSDAS TABLE library interface.
Users can customize and automate scripts of ASC calibration tasks using any of the UNIX Shell scripting languages, e.g., csh, Korn-shell, PERL. This provides a 4GL interface for user development that does not necessitate building compiled executables. Complex tools can be built from the general purpose tools. These general purpose tools can be customized either with a 4GL scripting language or using the 3GL C library interface.
For the flight system, existing pieces of the architecture will need to be expanded and some additional items will need to be integrated. This will be the focus of the ASC second critical design in the summer of 1996. However, the existing architecture of the layered interface should provide the mechanism for the system to evolve naturally from the calibration implementation to the the flight implementation. The Adaptation Wrappers can be expanded to include environments other than IRAF. The DDF/Data Manipulation layer can be expanded to include additional physical formats supported by independent I/O kernels. The final system must be portable to multiple platforms over a long time span.
This project is supported by NASA contract NAS8-39073 (ASC).
Van Stone, D., Conroy, M., & McDowell, J. 1996, this volume