The EOSDIS Core System (ECS) Release A supports the Tropical Rainfall Measuring Mission (TRMM), scheduled for launch August 1997. This first operational release of ECS will be delivered to NASA by December 1996, and provides a core set of functionality that will be enhanced by subsequent releases. The ECS Release A system will provide:
Consistent with EOS's 15-year observation plan, ECS Release A has a long-term evolutionary architecture to support satellite launches beyond TRMM. The Release A design team must balance system objectives and design drivers against the Release A schedule feasibility, bearing in mind that Release B follows only nine months later.
On August 14-18, 1995, the EOSDIS Core System project completed a highly successful Release A Critical Design Review in its Landover, Maryland facility. Total registration for the Critical Design Review included 350 representatives from Mission To Planet Earth-related NASA organizations, other government agencies, and Earth scientists and computer technologists from several universities.
The ECS Release A team presented details for the design of the Science Data Processing Segment and Communications and System Management Segment. The Science Data Processing Segment design addresses four main areas:
1. Data Storage and Management--represented by the Data Server Subsystem, which provides the functions needed to archive science data, search for and retrieve archived data, manage the archives, and stage data resources for production.
A key driver in the architecture of this subsystem is the expected decline in costs for data storage and processing capacities concurrent with improvements in throughput and response times. In the long term, therefore, ECS will be best served with an approach which affords the full capabilities of database management to science data even though this approach cannot be fully implemented in the near future. Therefore, the Data Server Subsystem provides access to Earth science data in an integrated fashion through an Application Programming Interface that is common to all data/information layers. The Release A team has chosen to use Sybase as the Data Base Management System to manage Earth science data and implement spatial searching.
2. Data Search and Retrieval--represented by the science user interface functions in the Client Subsystem, data search support functions in the Data Management Subsystem, and capabilities in the Interoperability Subsystem which assist users in locating services and data of interest.
A key driver in the architecture of these subsystems is the need to evolve to meet the needs of a wider user community. Also, ECS should provide the basic underpinning for an Earth science workbench, the assumption being that some of the science community will be in a better position to develop local data visualization, search, and analysis tools that fit into the workbench. The client subsystem software will consist of graphic user interface programs, tools for displaying the various kinds of ECS data, and libraries representing the client Application Programming Interface of ECS services. ECS will also re-use an enhanced version of the Version 0 System Client to provide data search and access functions.
3. Data Processing--represented by the Data Processing Subsystem, which provides a processing environment for science software; and capabilities for long- and short-term planning of science data processing as well as management of the production environment provided by the Planning Subsystem.
In the near term, data processing and reprocessing will occur routinely in accordance with the established production plans. However, in the long-term ECS should be able to provide "production on demand," where higher level products are produced only when there is explicit demand for their creation. Release A provides an evolutionary path to a mix of routine production and on-demand processing as users ask for data not currently stored by the data architecture. The need to provide highly scalable and configurable processing resources is the main driver in the hardware architecture. ECS has selected Autosys as a Commercial Off The Shelf (COTS) product for managing production in a distributed, heterogeneous UNIX environment, and Release A is integrating the product with custom software designed to manage distributed, heterogeneous computing resources.
4. Data Ingest represented by the Ingest Subsystem, which provides interfaces to external applications, data staging capabilities and storage for a buffer of Level 0 data for approximately one year (so that reprocessing can be serviced from local storage).
The number of ECS external interfaces is potentially very large, and the interfaces can serve very diverse functions, such as high-volume ingest of Level 0 data and low-volume ingest of data from field campaigns. Thus, the ability to dynamically configure all or a large part of an external interface from standardized components is a key driver of the subsystems software architecture. Resiliency against failure and loss of ingested data is also a key driver for the hardware configuration.
Science Data Processing Segment applications follow a distributed object-oriented design, where software objects are distributed across many platforms at a given site or across several sites. For the software objects to communicate with each other requires a "distributed object" communications environment. The Communications and System Management Segment design provides this environment using off-the-shelf technology (Object Oriented-Distributed Computing Environment from Hewlett-Packard) augmented with some custom software. The Communications and System Management Segment infrastructure services are based on the Distributed Computing Environment from the Open Software Foundation. In the area of enterprise management, ECS has selected Hewlett-Packard Openview as the centerpiece of its system management solution, and is augmenting it with other commercially available agents, as well as custom-developed software.
During the Critical Design Review (CDR), board members raised issues concerning the ECS operations scenarios screens and DAAC involvement in the screens design; distribution media; support for user services; enterprise management; and several other topics. In response to these concerns, the ECS Release A team has taken a number of actions including: the establishment of an Enterprise Management Concept to explore industry standards and innovations in fault and performance management; publishing the ECS schedule for HDF-EOS development; the addition of 4 mm tapes as a distribution medium; plans to publish an ECS security plan in February 1996; and the ECS Requirements Traceability Matrix to show the mapping from system requirements to certain COTS products.
In addition, ECS Release A team also explored the possibility of extending the functionality of the Autosys/Autoexpert COTS product to replace the custom code planned for the Planning Workbench Component. After more-detailed analysis of the Autosys/Autoexpert capabilities, the ECS Release A team decided that the product was not mature enough to warrant the technical and schedule risk inherent in extending the COTS to Planning Workbench function. They presented the analysis in a meeting in September, 1995 and decided to proceed with the approach presented at the CDR.
Details of the Release A design presented at the review, results of prototypes and trade studies, and the ECS response to issues raised during the review can be found on the ECS Data Handling System via the World Wide Web at http://edhs1.gsfc.nasa.gov.
After a challenging spring and summer, the ECS team takes pride in its accomplishment: a highly successful Release A Critical Design Review and recommendation to proceed from an extensive review community. We now look to new challenges: the implementation, testing, and deployment of the first ECS operational system.