Woods Hole Oceanographic Institution, Quissett Campus, Carriage House, August 19-21, 1997
-- david Glover (david@plaid.whoi.edu), Panel Chair
Attending: David Glover (WHOI, chair), Mark Abbott (OSU), Peter Allan (Rutherford Lab), Bruce Barkstrom (LaRC), G. David Emmitt (Simpsons Assoc.), Bob Evans (RSMAS), Jim Frew (UCSB), David Halpern (JPL), Robert Haskins (JPL), David Nichols(JPL), Moshe Pniel (JPL), Skip Reber (GSFC), Victor Zlotnicki (JPL). Guests: Francesco Bordi (SWAMP), Frank Eden (NRC), Betsy Edwards (GSFC, Code170), Steve Goodman (MSFC), Sara Graves (UAH, ERG), Paul Hwang (PM project), Gary Johnson (CIESIN-SEDAC), Paul Kanciruk (ORNL), Martha Maiden (GSFC Code 170), Rick Obenschain (ESDIS), H.K. Ramapriyan (ESDIS), Joe Senftle (ECS)
19 members of the EOSDIS Panel, along with 13 guests, gathered at the Woods Hole Oceanographic Institution to discuss aspects of a nascent Federation that need immediate attention. There were, however, a number of events in the EOSDIS world that also needed attention and so the first day of the meeting was spent in briefings on these events. These minutes cover the salient facts of the briefings as well as a description of the Federation issues discussions. A white paper is being drafted to capture the discussions and recommendationsof the EOSDIS Panel and guests on the important issues surroundingmembership, governance, and interoperability.
Bruce Barkstrom presented a summary of his latest document detailing his EOSDIS cost model. In his report Bruce breaks the cost of EOSDIS down into people costs and hardware structural costs in an attempt to determine what really drives the cost of EOSDIS. When divided in this manner it becomes evident that the hardware is only 10% of the budget, networks areanother 10%, and maintenance and operations are about 23%. The largestsingle cost in the budget is development, consuming about 24% before theincreased costs associated with the increased effort to develop an operationalsystem; the cost of EOSDIS is largely insensitive to the data volume. Thesecost figures were arrived at by using the COCOMO model (from 1989) which isbased largely on the estimated number of lines of code (LOC) to be generated. In this case a line of code is counted whether it is what we typically think of as a program (C or FORTRAN) or whether it is part of the glue code thatholds the many commercial off-the-shelf (COTS) packages used on EOSDIS together. The cost of the development of these lines of code is a non-linearfunction of the LOC.
Barkstrom finished his presentation with a strategy forreducing the cost of EOSDIS. The embedded centralized development model currently in use is expensive; the cost of EOSDIS can be reduced by changing to a semi-detached mode of development model. He made a case for asubstantially decreased emphasis on documentation in this semi-detached mode. In addition, it is necessary to reduce the number of system components andrequirements to reduce the total overall work load. Finally, numericalexperiments with this model suggest that the development would be lessexpensive when done as independently distributed development jobs atindividual DAACs. Although this engendered considerable discussion, no consensus for a recommendation could be reached by those present.
Plans for August ECS Demonstration
Originally it was hoped that the EOSDIS Panel meeting would be held after the ECS demo/test. Unfortunately the dates for both this meeting and the demo/test did not allow for this. Nevertheless, Rick Obenschain presented the EOSDIS Panel with an update on the plans for and progress towards the demo/test in Landover. He reported that the contractor was on schedule for the demo/test and that of the criteria developed previously by a group of people selected from the EOSDIS Review Group (ERG), which included the chair of the EOSDIS Panel, ECS had obtained an 85-86% success rate.
NASA's EOSDIS Alternate Implementation Plan (EAIP)
After Obenschain's briefing, he discussed the EOSDIS Alternate Implementation Plan (EAIP). At that time the EAIP was being planned in case the ECS contractor failed to make a critical delivery in time for the AM-1 launch, consequently their planning was constrained by the fact that they could not rely on anycomponent of ECS being available. The path they selected for the EAIP would be best described as a hybrid approach wherein the EAIP would be built upon theintegration and enhancement of currently available, non-ECS systems, such as Langley TRMM Information System (LaTIS), GSFC TRMM Science System (TSS), Version 0 (v0), the DAACs, and the SCFs currently supported Emergency Back-upPlans. They would follow two basic rules of operation for the EAIP: decentralized implementation management and decentralized architecture. The EAIP was compared to the EOSDIS baseline architecture and potential advantages (direct Instrument Team control of higher level products, increased flexibility during algorithm validation, increased IT and DAAC ownership) and disadvantages (increased schedule risk, IT distraction from research andscience, failure to satisfy EOSDIS system-wide requirements) were identified.
Report from the EOSDIS Review Group (ERG)
Sara Graves, Chair of the ERG, gave a report on the meeting ERG held in April 1997. She reviewed the group's charterand provided an overview of the recommendations that came out of theirfirst meeting. This group is charged to look at EOSDIS from a long time-scale,NASA- HQ pointof view. Consequently they are interested in the current statusof EOSDIS as well as the prospects for the AM-1 and PM-1 eras and beyond. Thefive month slip by ECS and the consequent cancellation of ECS Release A (tosupport TRMM) was discussed. For the AM-1 era, the ERG recommended that theAugust demo/test should have clear, unambiguous criteria and that feasiblebackup plans (EAIP) be made in case ECS did not meet these criteria. It was atthe April ERG meeting that the DPRB (Skip Reber, chair) was renamed the Data Processing Resources Board (DPRB) with Skip Reber (EOSDIS Project Scientist)chair. In the PM-1 era and beyond, the following recommendations werepresented. In particular, the MTPE program should develop lower-cost options that provide appropriate functionality for EOSDIS or its successor. The MTPE program should engender alternative architectures for EOSDIS and present themto the scientific community in terms of trade-offs between cost and functionalities. Graves said it is NASA HQ'sdesire to make the ERG into a standing committee and that the ERG would meetin October 1997 to discuss this and the results from the August demo/test.
Data Product Cut-back Percentages
Skip Reber presented the mandate from NASA HQ that EOSDIS reduce the datavolume at launch and follow a prescribed schedule to ramp up to full processing. At launch, Level 2 and higher data products will be produced at 25% of original volume. Level 2 and higher data products will ramp up to 50% at the end of the first year and to 75% at the end of the second and finally reach 100% at the end of the third year. This applies only to Level 2 and higher products. All Level 0 and Level 1 data will be captured, processed andarchived. Reber explained the further restructuring of theDPRB since the April ERG meeting. Now the resource allocation process will have two parts: a peer review group (not the DPRB) to give scientificrationale for resource allocation based on the data product maturity and the DPRB which will help implement these reviews/recommendations.
Based, in part, on Bruce Barkstrom's presentation, we are convinced that costand data processing rates are not tightly linked. Since data volume is not amajor cost driver, and if one can reduce computational requirements via algorithm/coding improvements, some participants wondered if EOS canramp up production at a faster rate than that proposed at present?
Next Generation InterNet
Bob Evans gave a brief review of the status of next generation internet (NGI)activities. Actually there are at least three activities aimed at providingmulti-megabit network services to affiliated academic and agency users (NGI, vBNS, and InterNet-2) which sometimes operate separately and sometimes overlap. The NGI is driven by government agencies and tends to be top-down and slow to implement. The InterNet-2 is more of a bottom-up academic drivenendeavor and tends to have a grass-roots flavor. The InterNet-2 to vBNS (veryhigh speed backbone network services) connectivity is an user-paid-for effort and the NGI/vBNS connection has very restrictive access rules. Since the NASA Science InterNet (NSI) is getting out of the business of being a network access provider, the transition to NGI/I-2 is really a strong candidate to provide high capacity network access to EOS products following a transitionperiod that will likely last several years. It is our expectation that thistransition will be rocky at best. There is a NSF program called "Connections" that will be the university pathway for most university internet users. Interestingly enough, the I-2/NGI is expressly forbidden to connect to the commodity internet (what we think of as the regular internet) so once you'vemade the transition to I-2/NGI you will no longer have access to AOL. Your institution will need to maintain its traditional Internet access arrangementsto connect to services (other users) not connected to the newer networks.
SOMO/CSOC/SIS-Study Plans
Skip Reber led a discussion of what the SOMO/CSOC/SIS effort at Johnson Space Center is and where it is heading. Earlier this year it was decided that all of NASA's data handling activities would be handled by a single contractor. This job was given to the Space Operations Management Office (SOMO) at JSC and they created the Consolidated Space Operations Contract (CSOC). Originallythis activity was aimed at handling things like TDRSS traffic, the spaceshuttle telemetry, etc. It was then pointed out that science data could alsobe handled in this manner. The science data (both space and Earth science)would be handled by the Science Information Services (SIS). The chair of theSIS steering committee (John W. O'Neill) appointed a SIS-study team (chaired by Cheevon "Mi-Mi" B. Lau) to "recommend cost effective science information services that will allow resources to concentrate on science and technology, but yet continue to provide high quality data products and services." The SIS-study team is composed of NASA representatives from codes M, S, U, and Yand is further advised by a lead customer group. The SIS-study team held its first meeting August 19-21, and a report recommending cost effective science information services is dueto the steering committee by the end of this year. It deals with general recommendations on best practices and who should be responsible for differentactivities. Next year the group will look at a representative set of missionsto determine if cost savings can be achieved if they follow those practices. The EOSDIS Panel had a lively discussion regarding the nature of this study which is summarized in one of the specific recommendations at the end of theminutes.
Federation Discussions
The remainder of the EOSDIS Panel meeting was given over to discussing the nature of federations and issues that will need to be addressed by the nascent; documents were made available to the panel prior to the meeting. At the meeting the federation discussion was started by a presentation ofexamples of federations and federation concepts by David Glover. The VISA Corporation and the Internet Engineering Task Force (IETF) were presented asthe examples and the science of federalism concepts from J. Gabrinowicz's (University of North Dakota, Department of Space Studies) writings weregermane to the discussions.
After the initial group discussion, the gathering was divided into three sub-groups with two of the three nascent federation issues to further discuss. These three issues were: membership, interoperability and governance. The overlap in discussion topics was done to encourage cross-fertilization of ideas when the sub-groups returned to report at the plenary at the end of themeeting. The membership issue dealt with the question: What makes one eligible for membership in the Federation and what does not? For the inter-operability issue, the sub-groups concentrated on the standards the Federation must impose upon itself to make it work. For the governance issue, the sub-groups discussed the systems of checks and balances the Federation must have in place to resolve Edisputes both within and without the Federation and NASA's unique role in this Earth science data federation. The proceedings from these discussions will be detailed in a white paper before the NRC Constitutional Convention.
Specific Recommendations
(1) One-Stop Shopping: The EOSDIS Panel recommends that EOSDIS concentrate on the one-stop-shopping aspects of the WWW for finding and obtaining data.
This is due, in large part, to the recognition that the EOSDIS user communityis now becoming comfortable with multiple WWW interfaces for findinginformation and that there are diverse data structures and data access methodsrequired by EOS data producers and data users. In this context we are referring to one-stop-shopping as equivalent to being able to search all DAACs for all occurrences of the specified data inside a specified or defaultedspace time window from a single graphical user interface. We have concludedthat this requirement has placed an undue burden upon the developers of ECS and acts as a software development cost driver. In addition, we are notconvinced that the maintenance cost beyond the software's initial release will be manageable in the future, particularly in the time frame beyond PM-1. Instead the EOSDIS Panel recommends that the ESDIS project and the ECS contractor provide a well-documented, public interface to enable users todevelop or use the paths they find most efficient in searching for the data that interests them. This interface is important because it will encouragecontinued innovation in search engines and user interfaces, including subsetting and coincidence search tools, in the form of additional software development beyond AM-1. Most of all, use of WWW technology will maximize theleverage of the commercial investments in that technology.
We wish to avoid the possibility of misunderstanding this recommendation. Itis not our intention to cancel or delete the concept of one-stop-shopping from EOSDIS, but rather change its emphasis. To facilitate this approach, the Panelrecommends that the ESDIS Project and the ECS contractor get JEST online andavailable to users as soon as possible. In other words, this interface toolmust be available in time for user feedback to make a difference before thelaunch of AM-1. We (as a community) need to balance the desire for costsavings through redirected emphasis of one-stop-shopping on WWW technologies and our strong desire to see JEST completed as soon as possible. We remainconcerned that any exercise along these lines not pull the rug out fromunderneath the interoperability potential of EOSDIS in the name of costsavings.
(2) SOMO/CSOC/SIS: The EOSDIS Panel recommends that the SIS-study group stop any study oncentralized design and focus on a de-centralized design for processing ofLevel 1 data (and beyond). Further, they should take careful note of lessonslearned from the EOS experience.
Upon review of the SIS-study viewgraphs presented to this group, we perceivethat the SIS-study is going in the direction of centralizing design with the goals of lowering costs, eliminating duplication and overlap. We cannot agreewith or condone this direction.
As part of the evolution of EOSDIS we have learned that a central solution tohandle MTPE data for EOS satellites, pre-EOS satellites and in-situ dataassociated with the above is unlikely to provide three key at- tributes: flexibility, robustness, and innovation. Flexibility brings to the users options for obtaining data and services. Innovation enables the system torapidly incorporate new technologies and new services. And finally, robustness guarantees that the system will be able to provide adequate services in case offailure of any one component. In addition, we have learned that the L0 processing contract for EOS has been quite successful. The Level 1 (and beyond) processing requirements are instrument unique and cannot be centralized in acost effective manner.
An architecture built around a set of small, "modular", distributed servicesand responsibilities, provides much less organizational inertia than a central design. Data processing needs to be under the authority and responsibility of those that understand the data. The concept of a centralsolution, possibly implemented by a single contractor, to meet the disparateneeds of processing, quality control, browsing and distributing Levels 2 orhigher science data to oceanographers, planetary geologists, andastrophysicists does not seem to us to be practical nor likely to besuccessful. We need only look to the NRC report (July 1995) wherein theydirected MTPE to retain as a centralized activity only the down-linking of data from the satellite, and its Level 0 and perhaps Level 1 processing,and to distribute the higher level processing and data distribution to a"Federation" of competitively-selected data processing partners.
(3) ESDIS Efficiency: The EOSDIS Panel recommends that the MTPE program allow the ESDIS project to"build to cost" within reasonable time windows.
During the course of this EOSDIS Panel meeting we were presented with strongevidence that ESDIS is being kept from managing the EOSDIS project efficientlydue to "fire drills" imposed upon them by higher NASA management. While weconsider the source, there does seem to be a problem and we suggest that thebudget trimming process could be made more rational by giving the scientific community more visibility into the process by which cost containment decisions are reached. In the past, with the involvement of the science community, restructuring/reshaping/rescoping exercises involved the ESDIS Project coming up with options for requirement reductions and cost savings associated with them and the EOSDIS Panel and/or Payload Panel advised them on priorities and accepted or rejected their recommendations. In this manner, priorities and associated costs were established and the flexibility for the project to work the problem within a specified cost target, in partnership with the scientific community, was and can be realized.