The NPOESS Preparatory Project

The NPP satellite is scheduled for launch in 2007 into a circular sun-synchronous polar orbit at a nominal altitude of 824 kilometers and a 10:30 a.m. descending node. This orbit provides a 16-day repeat cycle (8-day quasi-repeat), similar to that of the EOS satellites. The NPP satellite will carry the Visible Infrared Imager/Radiometer Suite, the Cross-track Infrared/Microwave Sounder Suite (consisting of the Cross-track Infrared Sounder and the Advanced Technology Microwave Sounder), and the Ozone Mapping and Profiler Suite. (Ball Aerospace and Technologies)

The NPOESS Preparatory Project: Architecture and Prototype Studies

Samuel Gasster, Sheri Benator, and David Bart

Aerospace helped NASA develop a system segment architecture for the NPOESS Preparatory Project using C4ISR as well as an advanced ground system prototype design using grid computing technology.

The National Polar-orbiting Operational Environmental Satellite System (NPOESS) represents a convergence of systems previously operated by the Department of Defense and the National Oceanic and Atmospheric Administration (NOAA). Scheduled for launch in 2009, it will support a broad range of activities in global environmental monitoring, meteorology, and climatology.

The NPOESS Preparatory Project (NPP) is a joint mission managed by NASA's Goddard Space Flight Center and the NPOESS Integrated Program Office. It provides NASA with a bridge for continuing the global-change observations of the Earth Observing System (EOS) while awaiting full NPOESS operational capability. It also serves as a risk-reduction mission for NPOESS, flying early versions of key sensors and deploying portions of the ground segment. The NPP satellite will be launched into a circular sun-synchronous polar orbit similar to that of the current EOS satellites.The current estimate is a launch sometime in fiscal year 2007.

This article describes architecture and prototype studies performed by Aerospace in support of the NPP mission. During the course of these studies, the NASA acquisition strategy for NPP was changed. As a result, NASA did not directly apply the results of the architecture and prototype studies to the acquisition of an NPP ground system; however, the results of these studies provided both NASA and Aerospace with valuable lessons learned on many aspects of ground system architecture and design.

The Science Data Segment: An Overview

The NPOESS Preparatory Project consists of space and ground segments. One of these, the Science Data Segment, became a particular area of focus for Aerospace. NASA asked Aerospace to assist in the acquisition of the Science Data Segment in 2000. This task initially focused on the development of a baseline specification for the segment architecture and related requirements, although the scope of this work later expanded to include architecture and requirements studies.

The primary function of the Science Data Segment is to facilitate the ingestion of raw data records from the Interface Data Processing Segment. These records consist of raw sensor data packets that have been downlinked from the NPP satellite. They are converted to engineering units, calibrated, and geolocated to create Level 1B data products, similar to NPOESS sensor data records. The Level 1B products are the primary data sets used by the NASA science team and other researchers to generate high-level data products and science-quality climate data records. The Level 1B products and climate data products are made available to the NASA science team and stored via the Archive and Distribution Segment.

NPP segments (with procuring agency by color). RDR—raw data record; SDR—sensor data record; EDR—environmental data record; SMD—stored mission data.

The Science Data Segment will also perform a number of related functions. For example, when new sensors are first deployed, their on-orbit calibration must be verified, and the data products derived from these instruments must be validated using spatially and temporally coincident correlative observations. The Science Data Segment will perform the calibration and validation activities.

Climate data processing and analysis involves the development of lengthy time series based on decades of measurements that often link observations made by different instruments. As instruments age and algorithms improve, it often becomes necessary to reprocess many years of measurements in less time than originally required to collect and process the data. Thus, the Science Data Segment must also provide the capability to reprocess any data as the need arises.

Given the high data rates from the NPP sensors, the system is expected to generate 2 petabytes (2 million gigabytes) of raw and processed data products over the 5-year mission life. The Science Data Segment must provide for the processing, distribution, storage, and archiving of this data. All of these functions must be managed and scheduled to allow seamless operation.

Architecture Studies

One of the key tasks that Aerospace performed in support of the NPP mission was the development of a set of baseline architecture documents. The architecture was developed and documented in accordance with the Department of Defense Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) Architecture Framework. This framework provides for the description of system architectures from three different, but related, perspectives: operational view, systems view, and technical view.

The operational view focuses on what the system must do to fulfill its mission; it describes tasks and activities, operational functions, and information flows. The systems view reflects the system being built, along with related functions and characteristics; it describes systems, segments, elements, subsystems, and interconnections providing or supporting mission functions. The technical view prescribes standards and conventions; it is the minimal set of rules governing the arrangement, interaction, and interdependence of the system entities.

For the NPP mission, these three perspectives are codified in a set of architecture documents that Aerospace developed and delivered to NASA. Aerospace was responsible for the first volume, Overview and Summary Information, and the third volume, System View. The second volume, NPP Mission System Description and Operations Concept, was developed by a separate group. The first volume contains a high-level description of the NPP mission and its environment. The third volume focuses on the system hierarchy (from system down to segment to element to subsystem) and associated capabilities and interfaces; it also includes a set of C4ISR views that illustrate and describe each project segment and element functionality and the external and internal segment interfaces. This architecture documentation supports the following systems-engineering functions.

Requirements Management. Preparation of a large number of requirements and operational concept documents began during the period of NPP formulation, which ran concurrently with the concept definition phase of the NPOESS program. The baseline requirements for the NPP program must remain consistent with the requirements baseline of the NPOESS program as they proceed through their respective phases of implementation. The NPP architecture helps correlate the operational activities derived from the system and operational concept with the system segments, elements, and subsystems being developed by the contractors.

Interface Engineering. Facets of the NPP mission include multiple contractors, each responsible for one or more segments, and, in certain instances, for one or more elements within a segment. These contractors support integration of their elements and deliver their products for final integration and testing. The NPP architecture supports the interface definition, compatibility check, and maintenance of complete external interfaces and intersegment interfaces where they cross contractor boundaries. It also supports the definition of intrasegment interfaces, which are needed when different contractors provide interfacing elements.

System Integration and Testing. The NPP architecture will support integration and testing at the mission level. Managers and planners use the architecture to help identify and define mission scenarios for end-to-end integration and testing. The architecture will help NASA determine which system elements are required for these tests. The mission scenarios will influence the formulation of integration and testing plans and procedures. NASA may also use the architecture to support similar activities at the segment level, though it's primarily geared to support integration and testing at the mission level.

The three volumes provide a comprehensive description of the configuration of the NPP system and its interfaces as well as the functionality and operations that allow it to meet mission requirements. They establish the controlled baseline architecture of the NPP system and its operations. They will be used to manage changes to the NPP architecture and operations over the life of the system. They also provide a means to introduce personnel and organizations to the fundamental characteristics of the mission.

Advanced Data Grid

While working with Aerospace to develop the NPP architecture documentation, NASA realized the Science Data Segment presented novel challenges in terms of ground system design and implementation. NASA asked Aerospace to suggest possible approaches for the Science Data Segment in early 2001. Based on initial architecture definition and requirements, Aerospace recommended an emerging technology known as grid computing (see sidebar, Grid Computing: An Overview). Because of the relative lack of maturity of this approach, Aerospace also recommended the development of a prototype implementation that would allow NASA to investigate key features as it moved to procure the full operational Science Data Segment. This prototype implementation was named the Advanced Data Grid.

The primary goal of the Advanced Data Grid project was to assess the applicability, effectiveness, and scalability of advanced data processing and data management technologies to the design and implementation of future Earth-science data processing systems. A key objective was to perform this assessment in the context of Science Data Segment requirements and workflow using grid computing technologies. An additional objective was to demonstrate the execution of a scientifically meaningful climate application requiring the management of massive data sets that would be representative of the type of application that the NPP science team might develop. Part of the overall task for Aerospace was to define this application.

An analysis of mission requirements determined the need to develop a ground data processing, storage, and archival system capable of handling data rates greater than 10 megabits per second, with possible reprocessing requirements of 20 times the data rate. The system would have to store and distribute petabytes of data to a geographically distributed team over the 5year expected mission life.

Grid computing seemed like a natural choice for the Science Data Segment prototype because it directly addresses the issues of integrating distributed heterogeneous resources as well as the dynamic scheduling of these resources, discovery and distribution of data for scientific applications, and the general sharing of computing resources. In addition, the system could be expanded as needed. Thus, the project office would not need to implement full system capability at the start, but could expand the system over the mission lifetime. This would allow better performance over time and significant cost savings.

Aerospace worked with NASA to define the Advanced Data Grid implementation. To simulate and test a wide range of representative workflows, researchers decided to not only set up sites at Goddard and Aerospace, but to incorporate the existing grid-computing capabilities developed at the Ames Research Center as part of the NASA Information Power Grid. Thus, the physical implementation for the Advanced Data Grid involved tying together resources at these three sites using the NASA Research and Engineering Network. Goddard provided the primary data processing and storage, Aerospace provided science user simulation and test management, and the Information Power Grid provided additional data processing and storage. The Advanced Data Grid team determined that petabytes of data would not be needed for the workflow simulations; rather, the testing could be performed using about 60 gigabytes of data and replaying the data where necessary.

Advanced Data Grid prototype architecture

Advanced Data Grid (ADG) prototype architecture involved the sharing of resources between three sites, with possible extension to a fourth. Goddard Space Flight Center (GSFC) provided the primary data processing, storage, and metadata catalog services. Ames' Information Power Grid (ARC/IPG) and Aerospace provided additional computing and storage resources. Aerospace provided a science user simulation capability as well. All sites were connected using the NASA Research and Engineering Network (NREN). MODIS sensor data was to be provided from Goddard's Distributed Active Archive Center (DAAC) using standard FTP downloads.

A major function that the Advanced Data Grid needed to demonstrate was the management of a large data set. The selected approach involved the implementation of a metadata catalog, tools for searching the catalog, interfaces to back-end storage systems, and tools for retrieving the found data sets. The implementation would then allow any user to search the metadata catalog using key words common to a specific problem domain. The search would return logical pointers to the data sets that match the user query. The pointers would then be passed to a replica location service that would identify the physical data set and allows data transfer to the user's designated site. Implicit in this process are the authentication and authorization mechanisms required to maintain information security.

Aerospace developed a plan and schedule that divided the Advanced Data Grid project into four phases to be executed over approximately three years. In the initialization phase, the basic hardware and software would be acquired and installed at each site; the team would also conduct internal testing and training, initiate acquisition of test data sets, develop additional project documentation, and install project configuration management tools. In the baseline phase, data grid functionality and interoperability would be demonstrated across all sites; the team would also establish benchmarks and start defining and developing science applications. Next, in the grid testing phase, the team would conduct major data grid testing, performance analysis, and assessment. Finally, the application demonstration phase would perform an appropriate climate data application. The Distributed Active Archive Center at Goddard would serve as the primary source of test data (the team planned to use MODIS sensor data). The team was also exploring the possibility of developing a grid capability and a future grid interface between the Distributed Active Archive Center and the Advanced Data Grid.

Aerospace and Goddard were well into the initialization phase by summer of 2003, having implemented initial data processing and storage capabilities at Goddard, purchased computing hardware for the Aerospace site, and negotiated network access and Information Power Grid resource use. Then, faced with programmatic and budgetary constraints, NASA headquarters revised the acquisition plan for the Science Data Segment, and the Advanced Data Grid Project was cancelled.

Nonetheless, the Aerospace and NASA team members learned important lessons about ground-system design and implementation using grid computing technologies. Their experience suggests that grid-based ground systems architectures have considerable potential for a wide range of Aerospace customers because of their ability to support a wide variety of problem domains, provide cross-program interoperability, and enable distributed work flow. Grid-based architectures also have significant potential for cost savings over the life of a program by allowing the purchase of commodity computing hardware. This allows a program to keep pace with the rapid change of technology for reasonable cost.

One of the key benefits of grid computing is the creation of "virtual organizations" by enabling the sharing of computing resources across traditional organizational and administrative boundaries. This requires strong teamwork, the involvement of all the stakeholders, and careful negotiation of policy issues (e.g., security). On the other hand, the chosen approach to metadata catalogs did not allow for their federation, so metadata catalog services were a potential single point of failure; this issue will need to be addressed. Grid service standards are changing, and their support by vendors will need to be considered. Since the termination of the Advanced Data Grid project, grid and web service standards have somewhat merged with the goal of providing better implementation and stability.

Conclusion

Aerospace's architecture studies were completed in September 2004, and work on the Science Data Segment prototype was completed in August 2003. Even though the acquisition plan changed and NASA did not release a Request for Proposal as originally intended, these efforts have yielded significant benefits. For example, the architecture and specification documents that Aerospace developed for NASA will be useful in guiding future development of the Science Data Segment. In addition, both NASA and Aerospace have gained additional insight into ground systems engineering, system design and implementation, and grid computing as a result of these two projects.