Prototypes and Studies Status

March 1996 Report



Release A


CORBA

Type: Prototype | Status: Completed | Category: Technology

Release: A | Sub-System: C-CSS | Organization: SCDO

Purpose: Risk Mitigation | Technology Assessment

Principle Investigator: Ming Lu | Lead: Naveen Hota/Evan Winston

Evaluation Lead: Ming Lu | ESDIS Lead: Hal Folts

Start Date: August 1995 | End Date: November 1995 | Effort: 9 man months


Objective:

Continue CORBA product prototyping; Continue to track maturation of vendor software (performance, service availability, CORBA 2.0 specifications). Prototype and validate ECS migration strategy by testing selected services for trail migration (gauge difficulties, costs, etc.). Identify migration paths from OODCE implementation to full object implementations.


Approach:

Use Sun DOE beta version to judge maturity of product interoperability, product ease of use, and impact on development. Look at possible CORBA products built on top of DCE.


Evaluation Method:

Understand CORBA, OODCE, and DCE.

Implement object services specified by CORBA services and develop applications based on these object components.

Investigate mechanisms that enable CORBA objects to interoperate with objects implemented using OODCE.


Monthly Update:

December 1995 - Prototype is completed, and a prototype report is presented. Please refer to Technical Paper 813-RD-014-001 for the detail.

November 1995 - Carried out further testing of DOE Beta: Implemented a test application of the relationship object service, specifically, the "Containment" relationship for a set of distributed objects, enabling each to find the rest of associated objects.

Based on the previous implementation of persistence and delegation and by using interface inheritance, additional capability was given to the previously implemented ORB object--- namely, the property object service. This new feature allows a client application to attach attributes at "run-time" to the deployed object.

October 1995 - Implemented test suites based on client/server paradigm of distributed objects, using ORB of SUN DOE Beta. They include the following categories: Persistence, Delegation, Lifecycle, Naming, and Events.

August 1995 - Preparation was made for a presentation at CDR. Working with each of the Common Object Services available with Sun DOE version for evaluation. Preliminary findings were presented at CDR. External dependency: need delivery of Sun pre-beta DOE software. Use DEC Object Broker if Sun not available by 5-17-95.


Key Events:

Meeting with representatives from Digital, discussed features of Digital's CORBA product, ObjectBroker. The emphasis was on finding out if Digital has a plan to leverage the existing DCE besides DCE security.

Presentation to and task identification with NASA liaisons, Robert Groff and Cindy Della Torre, 10/25/95.

Presentation at Release A CDR.

Final report via a findings document.


Results:

December 1995 - Prototype completed. Prototype results are documented in Technical Report 813-RD-014-001.

November 1995 - Developed applications using relationship service and property service. See Monthly Update above for details.

October 1995 - Developed applications using naming service and event service. The event service itself contains four mini-applications that cooperate with each other.

September 1995 - Developed applications using persistence, delegation, and lifecycle object services.

August 1995 - Presentations made at Release A CDR for current status. Please see CDR documentation.


Documents:

Technical Report 813-RD-014-001.

Release A CDR presentation documents.

Final report via a findings document.


Key Risks:

T1, T6, P6



Core Data Server Prototype

Type: prototype | Status: Completed | Category: Engineering

Release: Release A | Sub-System: S-DSS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: N/A | Lead: Mark Huber

Evaluation Lead: Mark Huber | ESDIS Lead: Ben Kobler

Start Date: 10-May-1995 | End Date: 8/20/95 | Effort: 1.5 man months


Objective:

This prototype will explore encapsulation strategies for FSMS and DBMS products. It will also provide empirical data to performance modeling, in effect helping to calibrate our models. The prototype will explore implementation approaches for "functional" design and then feed back results into object models, adjusting services and attributes based on lessons learned. The prototype will also explore implementation approaches for database design(s). We will also obtain hands on experience with current choices for Data Server robotics and storage devices. Time permitting, we have set up an agreement with PDPS to do some interface exercising in the early August time frame.


Approach:

Define Requirements, perform design, implement design (build prototype), do complete benchmarking, do I/F exercising, prepare for CDR demos.


Evaluation Method:

Decisions made in concert with Ben Kobler.


Monthly Update:

August, 1995 - The CDS was completed and demonstrated at CDR-A. The prototype software and hardware configuration will continue to be used for system characterizations.

July, 1995 - Began coding and integrating.


Key Events:

Prototype reviews with Ben Kobler.

Demonstration of CDSP at Release A CDR.


Results:

Successfully exercised the archiving and retrieval of science data granule via a GUI interface. Performed simple temporal metadata searches on existing and newly inserted data. Finally, demonstrated catalog searching operability. The prototype is now available to support the collection of empirical data for validation of performance modeling.


Documents:

Plan printing


Key Risks:

T4, T7



DCE Encapsulation Prototype

Type: prototype | Status: completed | Category: Engineering

Release: Release A | Sub-System: C-CSS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: Evan Winston | Lead: Evan Winston

Evaluation Lead: Herron | ESDIS Lead: Folts

Start Date: November 1994 | End Date: 2-28-95 | Effort: 2 man months


Objective:

- Examination of using OODCE as an alternative to an ORB in the first releases of ECS.

- What is the cost of using OODCE.

- Suggest ways of encapsulating DCE interfaces.


Approach:

Study the ECS subsystem requirements for Rel A and B. Determine if ORB implementation is required for first ECS deliveries. If not is OODCE a viable alternative based on costs, functionality, and robustness.


Evaluation Method:

Prototype the OODCE software. Evaluate the functionality provided by OODCE, and compare costs and risks in moving from DCE to OODCE versus DCE to ORB.


Monthly Update:

August 1995 - Prototype completed (February 1995). See Document section for more detail. Presentations, trade table and justification paper written and described in CSMS PDR documents.

July, 1995 - Under review. Status unknown.


Key Events:

Effectively completed at PDR, February 1995.


Results:

08/31/95

Prototype has been completed. Please see Documents section for more detailed results.

12/23/94

Almost complete, the final report is pending. Both a paper on using DCE for Trader, and the CSMS monthly on OODCE trade will be used for the final report.


Documents:

Technical paper on the OODCE decision was presented during CSMS PDR. (Feb 95).

White papers on the DEC/Trader functionality and HP ORB have been produced on EDHS.


Key Risks:

A-7 Communications Service System Overhead

T-9 DCE Availability for Release A

P-6 OO Development Methodology (SW and SE)



Data Dictionary and Vocabularies

Type: prototype | Status: integrated | Category: Engineering

Release: Release B | Sub-System: S-DMS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: John Farley | Lead: Evelyn Nakamura

Evaluation Lead: Evelyn Nakamura | ESDIS Lead: Mike Moore

Start Date: 01-Oct-1994 | End Date: 26 Oct-1995 | Effort: 8 man months


Objective:

- Investigate the methods and technologies necessary to develop the ECS data dictionary service.

- Provide prototype code for the DD to provide definitions of terms for items based on the vocabulary of the discipline.

- Establish the service interface for a portion of the DD.


Approach:

The following schedule/approach will be used for this prototype:

- Define the prototype scope. This task will look at the current object model of the DD and the statements of functionality. The pieces necessary for prototyping will be puled out and documented. The reason for this is that we probably don't want to focus the prototype on things like backup.

- Revise the object model. The object model will be revised based on the scope of the prototype as defined in the previous task.

- Develop the server. The object model will be implemented in a server using the CSMS infrastructure pieces available.

- Develop the test drivers. Some test drivers will be built to exercise the service interfaces for demonstration purposes. This may include some primitive user interface that will be used to pose queries to the DD and see the definition of the terms requested.

- Test. The server will be tested. This is rudimentary tests just to assure that the prototype works when giving demonstrations.

- Schedule. This prototype runs from Nov 21 94 to March 9 94. (Extended through EP6 development end of Oct 1995 to enable trial implementation.) A DBMS will be selected based on initial results of the DBMS evaluation and the availability of the DBMS. The prototype will probably have to be upgraded to support the protocol and query language established through the Earth Science Languages and Protocols Study.


Evaluation Method:

- The development organization will use the test driver as well as inspect the code for possible reuse items.

- The success of the prototype will be based on the ability of the prototype to accept incoming queries and supply discipline specific definitions of terms to the user.


Monthly Update:

October 1995

Completed EP6 DD implementation. Code Reviews held. Based on evaluations from EP6 this will form basis of Rel B DD implementation.

July 1995

Prototype interface and database were used to support PW1. DD is being integrated into the incremental track.

4/24/95

Data dictionary database has been populated using the GSFC metadata. Server is under development. Hughes Class Libraries are being used for client-server development. It is being investigated if we can add attribute aliases and acronyms to the data dictionary for prototype workshop 1.

03/24/95

Recommend the use of Sybase and its Replication Server for replicating the dictionary information across the sites. Results of the evaluation and architecture of the replication environment will be distributed in a future paper. GSFC data is in Oracle in the EDF. This will be used to populate keywords and attributes for the data dictionary prototype.

Evaluating the Sybase Replication Server as a means of replicating schema and data dictionary information from one site to another. This same schema will be used by the LIM prototype. The data dictionary will be populated with the GSFC metadata and attributes definition for inclusion in Prototype Workshop 1.


Key Events:

PW1

EP6 completion and evaluation.


Results:

Completed the Data Dictionary prototype in May 1995. The prototype was first evaluated during PW1. Feedback from PW1 was rolled into the incremental track version developed for EP6. The EP6 feedback will be rolled into the EP7 version of the Data Dictionary. The prototype and PW1 feedback provided key direction to the follow-on development for EP6.

The functionality demonstrated at PW1 included searching the Data Dictionary for definitions of instruments, platforms, acronyms, glossary terms, parameters, etc. The user was allowed to enter free text to search the database. The prototype was primarily of the user interaction with the Data Dictionary. It laid the ground work for the functionality of the Data Dictionary Service provided in EP6.


Documents:

A document was published internal to the ECS project describing the approach for replicating the Data Dictionary database across DAACs. This paper includes evaluations of COTS software that cannot be widely distributed, thus it is not available on EDHS.


Key Risks:

U-2: Interoperability of Earth Science Data Models

T-7: Database Management Systems Technology

A-5: User Interaction with Archived Data



Data Server I/F

Type: prototype | Status: In Progress | Category: Engineering

Release: Release A | Sub-System: S-DPS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: Karin Loya | Lead: Mark Shannon

Evaluation Lead: N/A | ESDIS Lead: N/A

Start Date: 03-Mar-1995 | End Date: N/A | Effort: 2 man months


Objective:

Integrate selected portions of processing with the data server to explore various aspects of data staging and its optimization of resources.


Approach:

Produce a detailed plan, code to plan, test and evaluate.


Evaluation Method:

Awaiting implementation assignment, prototype team will interface with data server team.


Monthly Update:

September, 1995 - We are in the process of integrating IR-1 Data Server public classes with Processing CSCI prototype software.

August, 1995 - This prototype is just getting started. With the selection of the AutoSys/AutoXpert products to support the Data Processing subsystem, and the update of the Processing CSCI detailed design to show COTS integration strategies, the Data Server I/F prototype can now begin in earnest.

July, 1995 - None.


Key Events:

N/A


Results:

In Progress


Documents:

N/A


Key Risks:

S2



Data System Server Configuration

Type: study | Status: Complete | Category: Engineering

Release: Release A | Sub-System: N/A | Organization: SCDO

Purpose: requirement clarification

Principle Investigator: Mark Huber | Lead: Ben Kobler

Evaluation Lead: N/A | ESDIS Lead: N/A

Start Date: 8/1/95 | End Date: 11/15/95 | Effort: N/A man months


Objective:

This study pulled together and documented, in detail, the hardware and high level software configuration of the data server subsystem. Each Release A site has detailed requirements and configurations. Release B sites will have configurations completed by CDR-B


Approach:

Outline, do research, do analysis, write document.


Evaluation Method:

Critical review of the documented data server configurations by ECS and ESDIS data server personnel.


Monthly Update:

November, 1995 - Study complete

October, 1995 - Study delivered to ESDIS for comments. Information incorporated in Release B IDR configuration documentation.

August, 1995 - Completed first draft of study. Study in review cycle.

July, 1995 - Research on material completed.


Key Events:

Feeds design review documentation


Results:

October 1995 - Preliminary Release B configurations folded into Release B IDR DAAC-specific configuration documentation.

System configuration concisely documents drivers and sizing for release A configuration.


Documents:

Release A GSFC DAAC Design Specification for the ECS project, 305-CD-014-001

Release A LaRC DAAC Design Specification for the ECS project, 305-CD-015-001

Release A EDC DAAC Design Specification for the ECS project, 305-CD-016-001

Release A MSFC DAAC Design Specification for the ECS project, 305-CD-017-001


Key Risks:

None



Data Type Services

Type: prototype | Status: completed | Category: Engineering

Release: Release A | Sub-System: S-DSS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: Evelyn Nakamura | Lead: Evelyn Nakamura

Evaluation Lead: Evelyn Nakamura | ESDIS Lead: Ben Kobler

Start Date: October 1994 | End Date: January 1995 | Effort: 18 man months


Objective:

(Note : This is a phased, multi-part prototype. Phases which follow appear in chronological order, with most recent updates appearing last)

DBMS Evaluations

- Evaluate DBMS technology as it relates to the functionality of the Data Type Services. Select the multiple DBMSs to be used to test performance and usefulness as it relates to the Data Type Services. Spatial queries will be part of the main focus in the performance testing.

- Present results as part of the DBMS Evaluation technical paper.

- COMPLETED JANUARY 1995

DBMS Benchmarking

- Provide realistic Performance measurements for candidate DBMSs (OODBMS/ ORDBMS/ extended RDBMS). This should validate or invalidate the query performance requirements in DID 216.

- Provide reliability and use ability metrics to the DBMS evaluation.

- Evaluate solutions for providing spatial indexes in DBMSs.

- Present results of benchmarking in a technical paper.

- COMPLETED JANUARY 1995

Data Server Architecture Study

- Focus on non-performance issues of the DBMSs used in the Phase II benchmarks. Evolvability, extensibility, scaleability and operability will be the focus of this study.

- Provide a COTS integration architecture that will support the non-performance requirements.

- Present results of architecture study in a technical paper and at Release A PDR. - COMPLETED JULY 1995

Core Data Server Prototype : Metadata Data Type Service

- Provide a prototype of the Data Server, using a design based on the COTS integration architecture presented in Phase III.

- Exercise the DBMS wrapper interfaces and integrate the Sybase COTS product into the prototype. Implement a subset of the Release A Data Server metadata database design.

- Demonstrate the services of search, acquire, and insert during Release A PDR.

-COMPLETED AUGUST 1995

Prototype Support of EP6 Incremental Track

- Provide a prototyped data server to support the EP6 incremental track deliverable.

-COMPLETED OCTOBER 1995


Approach:

The following schedule/approach will be used for this prototype:

- Review RFI responses (due 7/8) to determine candidate DBMSs for prototypes. No more than 3 DBMSs should be scheduled. Incorporate the findings in the DBMS Evaluation white paper. (due 7/30)

- Start new working paper to document database design, performance criteria, performance tests, candidate queries (from user modeling scenarios). (7/1 - 9/23)

- Provide separate summaries for each product to briefly describe how the code will be written for each product. Either enlist vendors to do this or just work with them to do it. (7/30 - 9/30).

- Provide descriptions to vendors and incorporate feedback. (9/30 - 10/21)

- Have vendors install products and configure them for the problems described. (10/3 - 10/7).

- Write prototype code. The tests should include at a minimum the following: (1) timing for bulk loads of data, (2) timings for individual inserts of data, (3) timings for building indexes on the data, (4) execution of typical queries as defined in the scenarios. (8/31 - 11/15).

- A Phase II of the bench will be performed to differentiate the close competitors from the initial benchmark. The actual tests involved in Phase II are TBD.

- Further DBMS evaluation will be done between PDR and May. The design and coding of the data type services piece of the data server prototype for EP6 will occur between May and Sept. using the DBMS selected.

- Evaluate each product's ability to respond to non-performance requirements for evolvability, extensibility, scaleability and operability in a design based on the COTS reference architecture, (12/94 - 1/95).

- Design and develop a core data server prototype and demo at CDR- A (2/95 - 8/95).

- Modify core data server prototype to support EP6 Incremental Track deliverable (9/95 - 10/95).


Evaluation Method:

- The candidate DBMSs should be evaluated against the criteria specified in the DBMS technical paper.

- The success of the core data server prototype will be based on the ability to design, implement and demonstrate a subset of the Release A data server capability in accordance with the COTS reference architecture presented during PDR-A.


Monthly Update:

October 1995 : Unit testing with test drivers written by the data server team was completed in early October. The delivery of the prototype code to Integration and Test via CM was made on October 20, 1995, marking the conclusion of the Data Type Services prototype.

September 1995 : The Data Type Services of Search and Acquire are being augmented for inclusion in the EP6 issue of The Core Data Server Prototype. The Insert service is not being provided as part of EP6. The following features are being added to the CDSP for EP6 : OODCE infrastructure for distributed operations between client / server; low-end spatial search using rectangular boundaries; population of the archive and the database with data. science data and browse data from AVHRR 1 km NDVI, ERBE and ISSCP_C2 datasets; e-mail notification of ftp push and pull distribution.

August 1995 : The Core Data Server Prototype was successfully demoed during CDR-A, August 14-18 at the Hughes Landover Facility. The data type services of insert, search and acquire were demonstrated. Integration of the DBMS wrapper and metadata classes with the COTS product was a successful demonstration of the COTS encapsulation concept. The Sybase-specific interfaces for metadata insert and retrieval were confined to a few classes with well defined parameterized interfaces.

July 26, 1995 The prototype will focus on the services of query and acquire. AVHRR data has been selected as the ESDT for the prototype. Coding and unit testing of classes is progressing and integration is scheduled to begin in one week.


Key Events:

CDR-Demo of Prototype

EP6-Migration of the prototype to support EP6.


Results:

July 26, 1995

Because this portion of the data server was changed to formal track development following SDR, its success criteria is no longer tied to the EP evaluation process.

04/25/95

This prototype has been temporarily suspended to allow for more DBMS evaluation by the design team. The prototype will be continued at a later date. Expect no further status until at least May 1995.

2/13/95

The DBMS evaluation phase has been completed. The results are documented in 430-TP-003-001 and another yet to be released paper. Due to the sensitive nature of the results of these papers, they will be available to only ECS and ESDIS personnel or people designated by ESDIS with a "need to know". This information is kept private to foster competition between vendors an vendors that have been eliminated.

1/5/95

The DBMS evaluation continues with a design phase of the data server using WAIS DBMS. The issues and cost of implementing the data server with each product will be examined. This second phase of the evaluation is due to be completed in Jan. At the completion of the evaluation phase, the data type services prototype will begin with a selected DBMS.

11/7/94

The DBMS benchmarks are underway. All the products are in-house and 3 of the 4 have been installed. The due date for Nov. 15 may be slipped some due to logistics with some of the vendors as well as problems with hardware configurations, etc. A document has been written summarizing the plan for the benchmark. This document is available from the prototype lead and is not loaded on the EDHS.


Documents:

As discussed above, the "DBMS Benchmark Report" (430-TP-003-001), the "DBMS Evaluations" (440-TP-002-001) and the "Data Server Architecture Study" (440-TP-001-001) can be made available to ECS and ESDIS personnel.


Key Risks:

T-7: Database Management Systems

P-4: Resources for COTS integration Code



Distributed File Access Prototype

Type: prototype | Status: completed | Category: Engineering

Release: Release A | Sub-System: C-CSS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: D. Schoeman | Lead: N. Hota/E. Winston

Evaluation Lead: N/A | ESDIS Lead: Folts

Start Date: 01-Feb-1995 | End Date: 01-Aug-1995 | Effort: 6 man months


Objective:

- Evaluates alternatives with transfer interoperability testing; CF abstraction

- Evaluation of alternatives

- Transfer Interoperability testing

- OO environment abstraction/encapsulation


Approach:

Set up remote file access tests to support evaluation methods.


Evaluation Method:

Evaluate maturity of the product.

Evaluate the requirements that this product needs to provide for Rel A.


Monthly Update:

August 1995

Prototype Completed. Findings report (technical paper) was issued in Aug. 1995.

Results presented at SCDO CDR (August 95).


Key Events:

Mentioned in DID 305 CSS documentation and in the CDR presentation.


Results:

July 1995

DFS under DCE 1.0.3 is somewhat unstable will need enhancement expected in DCE 1.1 and DCE 1.2 releases. DFS will not be used as a delivery mechanism in Release A.

Impact: DFS should be prototyped again during Rel. A Ops by Rel. B Team. Replicated DFS servers should be part of the prototype.


Documents:

Communications Subsystem DFS/NFS Comparison for the ECS Project 530-TP-002-001


Key Risks:

A7, T9, T11



Evaluation Package 6

Type: prototype | Status: In-Progress | Category: Advanced

Release: Release A/B | Sub-System: multi- | Organization: SCDO

Purpose: requirement clarification

Principle Investigator: Evan Winston | Lead: Naveen Hota

Evaluation Lead: Jan Poston Day | ESDIS Lead: Ken McDonald

Start Date: June 1995 | End Date: March 1996 | Effort: multi man months


Objective:

Prototypes and incremental code development for release A/B. Support better requirements definition and provide for user feedback and evaluation of user interfaces, GUIs, functional operation. Feedback and evaluations are cycled into Rel A and B design and development. Provides users an early look at selected COTS and planned implementation of software. Refined level 4 requirements are fed back into release traces.

Please refer to the EP6 Documents (available on EDHS) identified in the documents section of this report. These documents detail the contents and the objectives of the EP6.


Approach:

Please refer to the EP6 Deployment and the EP6 Objectives Reveiw slide package available for detailed contents and approach of EP6.

EP development process as described in the EP Strategic Plan technical paper- Includes interaction with and evaluation by the user community throughout.

Release A components for EP6 include Desktop; MSS: Openview, Remedy (trouble ticket), and agent; CSS: OODCE framework (directory,security,rpcs); EOSView enhanced from EP4; Advertising Service enhanced from PW1 and Earth Pages; Data Server enhanced from the CDR demonstrations.

Release B components for EP6 include the Earth Science Search Tool (ESST); and the Data Dictionary service.

Note: not all functions and operations are provided for the services listed - just the ones that are being made available for this evaluation package.


Evaluation Method:

Large groups of tirekickers; DAAC Community. Trouble Ticket and User Comment Screen are filed by evaluators.

Science Users (tirekickers) and DAAC ops users to evaluate.

Useability Testing to be conducted in Landover (New EP6 users are observed by test personnel).


Monthly Update:

February 1996

Useability Testing has been completed. Due to some noted problems with user access to the EP6, changes were applied to parts of the client software in December 1995 and a new client was distributed to evaluators in January 1996. Other changes have been recommeded and were implemented in PW2; others have been recommended to EP7.

A number of changes on the local EP6 lan were made this month and upgrades to the router have been requested to improve user access. Closer UNIX admin is being provide to evlauation workstations that will also improve user access.

An extended evaluation period is planned from mid-March through March 31, 1996. The EP6 evaluation report will be published after the completion of this evaluation period.

November 1995 - Consent to Ship Review held (9 Nov 95).

October 1995 - I&T testing .

September 1995 - Code Inspections and Unit testing performed. Test Readiness Review.

August 1995 - Design Review Held. Coding in progress.

July, 1995 - Design Inspections were performed.


Key Events:

Requirements/Objectives Review - June 95

Design Review - August 95

EP Strategic Plan Technical Paper - September 95

Test Readiness Review (TRR) - Sept 95

Consent to Ship Review (CSR) - Oct 95

Evaluation Readiness Review (ERR) - Nov 17 95 (metric)

Evaluation Period for EP6 - ERR through end of Jan. 95 (extended through March 1996)


Results:

February 1996 -- Continuing to increase operational knowledge, while improving user access to EP6. Testing completed to allow scheduling of extended evaluation period in March 1996.

January 1996 -- Useability testing was started on Dec 16, 1995 and will be completed on February 16, 1996. The Evaluation report will be published by the end of March 1996 and will incorporate useability testing as well as user comments which will continue to be collected through March, 1996.

We are accumulating lots of invaluable operational information (lessons learned) that will help us in bringing EP7 and Rel A implementations on-line.

October 95 - In Progress. CSR rescheduled in part to avoid conflict with Rel B IDR.

Results: Evaluation Report to be issued by end of Feb. 96.


Documents:

The EP6 technical papers as available on the EDHS; the EP Strategic Plan includes the the details of the objectives and the contents of EP6. A paper on the EP6 Limitations and Workarounds is also available (also can be reached by html link from the EP6 Welcome screen). The EP6 Evaluation Report will be available by the end of March 1996.

EP Strategic Plan Technical Paper

Slides for EP6 Objectives Review, Design Review, Test Readiness Review, Consent to Ship Review, and Evaluation Readiness Review.

EP 6 Evaluation Report Technical Paper


Key Risks:

N/A



Extensible agent

Type: prototype | Status: completed | Category: Technology

Release: Release A | Sub-System: MSS | Organization: SCDO

Purpose: technology assessment

Principle Investigator: Kingsbury | Lead: Gary Forman

Evaluation Lead: Forman/Kingsbury | ESDIS Lead: N/A

Start Date: 19-Jun-1995 | End Date: 21-Jul-1995 | Effort: 1 man months


Objective:

Implement the Enterprise MIB defined in the Enterprise MIB prototype, and demonstrate extensible agent implementation. Demonstrate the capability to provide lifecycle (startup and shutdown) services for ECS applications and the ability for applications to log "events" to the management database for post processing and operator notification.


Approach:

1) Define one new branch for MIB1 to define ECS unique resources.

2) Implement MIB extension with COTS product (Peer Agent Tech.)

3) Extend agent to support MIB.

4) Instrument application.

5) Demonstration via reporting to HPOV of various instrumentation and event reporting.


Evaluation Method:

Demonstration. Command application to shutdown gracefully via HPOV commanding. Display graphic representation of metrics collected through the instrumentation of an application. Demonstrate agent ability to forward "critical" events to HPOV and provide visual and audible alert to the operator.


Monthly Update:

October, 1995 - Demonstrated at Release A CDR, Release B IDR and included in EP-6

July, 1995 - Completed.


Key Events:

Demonstration at CDR, Release B IDR, and EP-6


Results:

October, 1995 - Validated selection of Peer Agent for ECS extensions to support software/application monitoring.

Demonstrated ability to manage ECS software applications via the extensible agent and extended MIB. Verified design and capabilities of COTS agent development packages.


Documents:

Incorporated in MSS design.


Key Risks:

N/A



HPOV Configuration

Type: prototype | Status: Completed | Category: Engineering

Release: Release A | Sub-System: C-MSS | Organization: SCDO

Purpose: technology assessment

Principle Investigator: Scott Austin | Lead: Gary Forman

Evaluation Lead: Gary Forman | ESDIS Lead: N/A

Start Date: 02-Aug-1995 | End Date: 17-Aug-1995 | Effort: 0.5 man months


Objective:

To create a map hierarchy and configure HP Openview to reflect the views representative of a DAAC (such as the SDPS Subsystem and the CSMS Infrastructure such as DCE) and a view of the wan-wide resources. The view of the DAAC should reflect functional views of the managed objects at the DAAC. Demonstrate the capability of application integration at the menu bar with a series of cascadal menus.


Approach:

Incorporate interface with customized agent to support monitoring of ECS applications within HPOV, maintain status information on these applications, and provide both audible and visual alarms for failure conditions.


Evaluation Method:

Demonstration of HPOV configuration that incorporates interface to agent and status changes in real time.


Monthly Update:

January 1996 - Completed

This capability was demonstrated at the Release A CDR and Release B PDR with early prototype agent code. Objectives of the prototype were achieved and implementation of fully functional agent that interfaces with HPOV has been initiated based on these results.


Key Events:

Presentation at CDR


Results:

January 1996

Successful demonstration of the ability to display both ECS hardware and ECS software components in HPOV and maintain status on different types of resources. Integrated view of a typical DAAC configuration provided.


Documents:

Release A CDR presentation, also documented in DID 605 and presented at workshop.


Key Risks:

N/A



Ingest GUI I/F Prototype

Type: Prototype | Status: Completed | Category: Engineering

Release: A | Sub-System: S-INS | Organization: SCDO

Purpose: Risk Mitigation

Principle Investigator: LiLing Chao | Lead: LiLing Chao

Evaluation Lead: Carey Gire/LiLing Chao | ESDIS Lead: Ben Kobler

Start Date: 6/16/95 | End Date: 8/16/95 | Effort: 2 man months


Objective:

To generate prototype GUI screens for the Ingest Subsystem that will best fit the end-users' needs. The development will be based on the methodology and standards defined in the ECS Users Interface Style Guide document to ensure consistent look-and-feel system wide. The produced prototype screens will be used as the baseline for the final Ingest GUI interface in Release A (phase II).


Approach:

-Analyze/design the Ingest Prototype GUI Screens using the ECS methodology/standards.

-Implement the Ingest Prototype GUI screens via the BuilderXcessary toolcase.

-Present the Ingest Prototype GUI screens to the users community.


Evaluation Method:

Review the resultant Ingest prototype GUI screens with the DAACs and ESDIS personnel. Feed-backs from the reviews will be evaluated and incorporated into the final Ingest GUI Interface.


Monthly Update:

8/16/95 - Completed the Ingest prototype GUI screens


Key Events:

-CDR Prototype Demonstration

-Prototype Review with the ESDIS personnel


Results:

Six Ingest Prototype GUI screens:

-Hard Media Ingest

-Ingest Request Monitoring

-Ingest Request Controller

-Ingest History Log Viewing

-Ingest Threshold Controller

-Ingest Template Editor


Documents:

No documents were produced. The results were incorporated in to the Ingest Subsystem design.


Key Risks:

S1 - Scope of ECS operations in DAACs



Ingest Infrastructure Prototype

Type: Prototype | Status: Completed | Category: Engineering

Release: Release A | Sub-System: S-INS | Organization: SCDO

Purpose: Functional Enhancement

Principle Investigator: Carey Gire | Lead: Vincent Grella

Evaluation Lead: Carey Gire | ESDIS Lead: Ben Kobler

Start Date: 8/1/95 | End Date: 9/22/95 | Effort: 1 man months


Objective:

1. Verify that the hardware configuration for the Ingest subsystem can support performance requirements.

2. Determine the maximum sustained performance of the Ingest hardware configuration.

3. Identify the hardware and software components that constrain the performance of the Ingest subsystem. Determine the relative performance impact of each of these components on the performance of the subsystem as a whole.

4. Determine impact, if any, of system activities outside of the Ingest subsystem.

5. Identify software or hardware design changes required (if necessary) to achieve performance requirements.


Approach:

1. Measure the performance of the ECS file transfer software (1) under stand-alone conditions and (2) with competing network traffic.

2. Measure best-case magnetic disk performance while copying data from memory to disk under stand-alone conditions. Measure magnetic disk performance (1) with competing CPU loads, and (2) competing disk loads.

3. Measure best-case tape storage performance by copying data from disk to tape under stand-alone conditions. Measure tape storage performance (1) with competing CPU loads, and (2) competing disk loads.

4. Measure best-case end-to-end performance incorporating ftp I/O and disk to tape I/O. Measure end-to-end performance under various competing network, CPU, disk, and tape storage loads.


Evaluation Method:

The evaluation of the prototype will be based on direct measurements of hardware/software performance, and a comparison of measured performance against required performance. Measurements will be performed with loads comparable to those expected under operational conditions.


Monthly Update:

September 1995 -- completed integration with Core Data Server prototype.


Key Events:

Integration with Core Data Server Prototype.


Results:

N/A


Documents:

N/A


Key Risks:

N/A



Interprocess Communications Prototype

Type: Prototype | Status: Complete | Category: Engineering

Release: A | Sub-System: C-CSS | Organization: SCDO

Purpose: Risk Mitigation

Principle Investigator: Naveen Hota | Lead: Alicia Newhagen

Evaluation Lead: Alicia Newhagen | ESDIS Lead: Hal Folts

Start Date: December 1994 | End Date: February 1996 | Effort: 5 man months


Objective:

2/13/96

An objective of this prototype was to help to better define the communications requirements of FOS. Determine what CSS services would be used by FOS developers and to determine if any CSS services/APIs would need to be modified to meet the FOS needs. Additionally this prototype would provide risk mitigation by providing a dual path CSS development in case the HP OODCE port to DEC platforms ran behind schedule.

To develop a prototype to use in place of the OODCE on DEC platforms until a port can be completed by HP.

- Enables asynchronous and real-time communications support to FOS.


Approach:

March 1996

Further refine the FOS/CSS communications requirements.

CSS Message Passing implemented with RogueWave Net.h and the RogueWave Libraries (C++); hook with the DCE Directory services to run on DEC platforms.

Develop code for FOS to complete A1 coding tasks.


Evaluation Method:

Evaluate FOS development capabilities for A1. Validate the FOS IPC requirements.


Monthly Update:

February 1996 This prototype has been completed. CSS Code has been developed and is available to be used on DEC platforms. Please refer to the results paragraph below.

October 1995

Supported FOS CDR with the results of the IPC/HCL prototyping. Partial HCL solution has been demonstrated to FOS. Verifying the FOS IPC requirements for CDR.

August 1995

Reestablishing the prototype and objectives for FOS; Goal is to work on code for an October 1995 delivery for A1 FOS tasks.


Key Events:

FOS CDR - October 1995


Results:

February 1996

As a result of this prototype FOS and CSS have agreed on the FOS IPC requirements. A message passing API as published for the FOS CDR is the approved interface.

Since an OODCE implementation on DEC workstations was not available in time for FOS development to begin a partial implementation was made over a Rouge Wave tools. This will be used by FOS until the message passing over OODCE on DEC is available (expect Spring 1996).

October 1995

Supported FOS CDR with results of the IPC/HCL progress.

Re-evaluated the requirements for FOS IPC.

Re-evaluated the need to provide only one unified API for ECS IPC.

8/31/95

Expecting code to be completed in October 1995. Code will be evaluated in November 1995.

Results Prior to Re-establishment:

12/23/94

CSMS modified FOS code to use DCE/RPC threads. Work is expected to be complete by Feb. 1995.


Documents:

2/13/96

Documentation of the CSS provided communications services were provided in preparation for the FOS CDR. Refer to the FOS CDR volumes for the decriptions for the CSS provided servies and APIs.


Key Risks:

T-11 CSMS Service by Platform

T-9 DCE Availability for Release A

P-6 OO Development Methodology (SW and SE)



Job Scheduler COTS Integration

Type: prototype | Status: in-progress | Category: Technology

Release: Release A | Sub-System: S-DPS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: Karin Loya | Lead: Mark Shannon

Evaluation Lead: N/A | ESDIS Lead: N/A

Start Date: August 1, 1995 | End Date: N/A | Effort: 3 man months


Objective:

Prototyping of the interfaces to the job scheduling COTS selected for ECS to refine the planning and processing CI's design.


Approach:

Acquire and evaluate COTS. Procure selected package. Use COTS tools to develop prototype interface.


Evaluation Method:

Karin Loya, Mark Shannon, Martin and others do team evaluations.


Monthly Update:

September, 1995 - Have completed work with Planning and will now move into doing more performance type work.

August, 1995. Evaluation and prototyping with detailed design OO model has begun. At CDR, a demo made of the product and the functions provided by the product. This demo has been well received. As work continues on development software, this software will be integrated into the Product accordingly.

Stay Tuned....

July, 1995 - COTS was selected this month, installation begun. Platform evaluation begun.


Key Events:

CDR demo planned


Results:

N/A


Documents:

N/A


Key Risks:

P4



MSS Application Prototyping

Type: prototype | Status: Completed | Category: Engineering

Release: Release A | Sub-System: C-MSS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: C. Kingsbury | Lead: G. Forman

Evaluation Lead: N/A | ESDIS Lead: N/A

Start Date: July 95 | End Date: Sep 95 | Effort: 2 man months


Objective:

Prototype management of both COTS and custom software via HPOV. This prototype will utilize COTS agent development tools to demonstrate ability to modify the standard SNMP agent such that non-SNMP objects are managed.

COTS application trails - non- COTS application prototype.


Approach:

Develop a proxy agent to manage (start and stop) a COTS product from HPOV. Develop an application that is managed from HPOV.


Evaluation Method:

Demonstration. Provide visual demonstration of HPOV receiving events from applications, responding to startup and shutdown commands. For managed applications, show Icon turning red on HPOV map, alert to operator, and event logging in MSS and HPOV event log.


Monthly Update:

October 1995 - Application has been developed which incorporates the Management agent, provides instrumentation for collection of application metrics, and responds to startup and shutdown commands from the management server (HPOV).

July 1995 - Work is in progress.

Impact: Require an extensible agent and the development of an ECS MIB.


Key Events:

Presentation at Release A CDR, Release B IDR, and EP-6 delivered system.


Results:

January 1996

Prototype valided the concept of using a Proxy agent to manage COTS software that was not designed for SNMP management. Proxy agent provides common interface from MSS to all COTS software, simplifying ECS interfaces and providing upgrade path that isolates impact on other software. Life Cycle services can be provided for COTS that were not designed to support SNMP interface.

October 1995 - Implementation successfully completed and demonstrated at the Release A CDR, Release B IDR, and EP-6.


Documents:

Release A Design Specification, CDR demonstrations, and EP6.


Key Risks:

None



MSS Prototyping

Type: prototype | Status: Completed | Category: Engineering

Release: Release A | Sub-System: C-MSS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: Chris Kingsbury | Lead: Gary Forman

Evaluation Lead: N/A | ESDIS Lead: N/A

Start Date: 01-Oct-1994 | End Date: 01-Sep-1995 | Effort: 15 man months


Objective:

- Early prototyping of OO based systems management solutions.

- Template development

- SNMP management of non-network objects

- Tivoli Framework trial use

- Cluster manager/smart agent prototyping

- SNMP to GDMO object mapping prototyping


Approach:

Developing prototype of SNMP management of non-network objects. Perform studies of other objective areas.


Evaluation Method:

Demonstration


Monthly Update:

January 1996

Management of Non-Network objects/resources was demonstrated at CDR. Initial study provided information on MIB definitions and industry initiatives to standardize the management of such objects. Security and performance issues resulted in using RPCs for agent to MSS server communications for non-network objects (still using MIB based design but RPC protocol rather than SNMP).

July 1995

Developing alpha version of SNMP management of non-network objects using subagent architecture.


Key Events:

Demonstration of RPCs for management of ECS applications at CDR, SNMP used for host computers and peripherals where SNMP agents provided by vendors. SNMP being used for get operations only, due to security Set operations are done through RPCs.

Demonstration of SNMP management of non-network objects at CDR.


Results:

January 1996

Prototype completed and presented at Release A CDR. Continuing to follow industry initiatives which includes Application Management Specification from Tivoli, which provides entree into CORBA based application management in future releases.

July 1995

Studies completed 12/94. SNMP management of non-network objects prototyping on-going.


Documents:

Findings report, demonstration at CDR.


Key Risks:

N/A



Message Passing

Type: prototype | Status: completed | Category: Technology

Release: Release A | Sub-System: C-CSS | Organization: SCDO

Purpose: technology assessment

Principle Investigator: Naveen Hota | Lead: Naveen Hota

Evaluation Lead: Evan Winston | ESDIS Lead: Folts

Start Date: December 1994 | End Date: 15-Jul-1995 | Effort: 4 man months


Objective:

This prototype identifies and evaluates different mechanisms to provide asynchronous message passing between processes residing in different address places. It also determines how to implement this service in ECS.


Approach:

Select and evaluate several COTS products versus a build in house effort.


Evaluation Method:

Acquire, install and evaluate COTS products and compare versus requirements. Analyze the effort to build versus buy versus the requirements Team effort with joint decision making, Evan Winston and Naveen Hota.


Monthly Update:

July, 1995 - Final decisions were made.


Key Events:

Feeds Release A CDR


Results:

July 1995

Decision made not to buy COTS product. Each COTS failed to satisfy ECS requirements. Queuing and threads problems. Decision finalized to build capability in house.


Documents:

Message Passing Evaluation Technical Paper prepared - posted on EDHS.


Key Risks:

N/A



Network Management Prototype

Type: prototype | Status: Completed | Category: Engineering

Release: Release A | Sub-System: MSS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: C. Kingsbury | Lead: Gary Forman

Evaluation Lead: Gary Forman | ESDIS Lead: N/A

Start Date: 01-Oct-1994 | End Date: 05-Jun-1995 | Effort: 1 man months


Objective:

Early prototyping of network management Custom Agents.


Approach:

Install custom agent on Sun platform.

Integrate agent to HPOV.

Provide notification to FOS.


Evaluation Method:

Inspection/Demonstration


Monthly Update:

October 1995 - no new activity, demonstration successfully completed

July 1995

No activity, activity has completed.


Key Events:

Demonstrate with FOS

Demonstrate at CDR


Results:

October 95 - Successfully completed and incorporated into CDR design and demonstrations presented at the Release A, FOS, and Release B Reviews.

7/31/95

Demonstrated management of custom H/W with other subsystems.

12/23/94

Work is almost complete; the final report still needs to be written.


Documents:

Incorporate in ECS design. Provide guidelines for applications to incorporate management and metrics in design.


Key Risks:

N/A



ORB Prototyping

Type: prototype | Status: completed | Category: Engineering

Release: Release A | Sub-System: C-CSS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: Evan Winston | Lead: Tom Herron

Evaluation Lead: N/A | ESDIS Lead: Folts

Start Date: July 1994 | End Date: December 1994 | Effort: 4 man months


Objective:

- Examination of HP ORB+.

- Examination of Sun DOE.

- Examination of other ORB implementations; CF abstractions.

- Common Facility Prototyping of Sun DOE CF, NextStep, other prime picks.

- Interface Abstraction for Release A CSS service.


Approach:

Acquire software for prototyping. Start with HP ORB+ as it is written over DCE services and thus provides a better frame of reference to Rel A requirements.


Evaluation Method:

Evaluate the operation of the ORB product. Assess differences between vendor products. Does ORB meet Rel A requirements?


Monthly Update:

August 1995 - This prototype has been incorporated into the CORBA prototype after the CSMS PDR. See CORBA Prototype for more information.

July, 1995 - Under Review. Prototype may be merged with CORBA and ORB/Object Services prototypes.


Key Events:

A presentation of the report was made at CSMS PDR (Feb 95).


Results:

8/31/95

This prototype has been incorporated into the CORBA prototype.

12/23/94

Examined HP ORB+. Obtained early developers release of Sun's Distributed Objects Everwhere (DOE) product and we are working on a beta release site agreement with this Sun DOE product (expect in Feb 95), in collaboration with HRL on use of ExperSoft. Also starting to examine ObjectBroker by DEC (version 2.6 may be over DCE - release mid-95).


Documents:

Findings Reports, and a presentation was provided at the CSMS PDR (Feb. 1995).

White Paper on HP ORB+ prototyping findings was provided (Dec, 1994).


Key Risks:

T1 - Availability of CORBA Immaturity for Release B.

T6 - Performance of Communication Infrastructure.

P6 - OO Development Methodology (SW and SE)



ORB and Object Service Abstraction Prototype

Type: prototype | Status: completed | Category: Engineering

Release: Release A | Sub-System: C-CSS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: Evan Winston | Lead: Naveen Hota

Evaluation Lead: N/A | ESDIS Lead: Folts

Start Date: N/A | End Date: N/A | Effort: 6 man months


Objective:

2/13/96

This prototype was merged with the CORBA prototype; please refer to the CORBA prototype write-up which can also be found in the Release A prototypes listing.

- Prototypes ORB and object services abstractions for vendor interoperability.

- Multiple Vendor ORB, Object Services, and Common Facility Prototyping

- Interface Abstraction for Release A CSS services.


Approach:

N/A


Evaluation Method:

N/A


Monthly Update:

August 1995 - This prototypes objectives have been merged with the new CORBA prototype.

July, 1995 - Under Review. Prototype may be merged with CORBA and ORB prototypes.


Key Events:

N/A


Results:

2/13/96

Since this prototype was merged with the CORBA prototype; please refer to the release A CORBA prototype write-up for further information.

8/31/95

This prototype has been officially closed. It's objectives were merged with the CORBA prototype.


Documents:

2/13/96

Since this prototype was merged with the CORBA prototype; please refer to the release A CORBA prototype write-up for further information. A separate findings report as not issued; please refer to the CORBA prototype report.

Findings Report


Key Risks:

T1 - Availability of CORBA Immaturity for Release B.

T6 - Performance of Communication Infrastructure.

P6 - OO Development Methodology.



Planning Subsystem Prototype

Type: prototype | Status: completed | Category: Engineering

Release: Release A | Sub-System: S-PLS | Organization: N/A

Purpose: risk mitigation

Principle Investigator: N/A | Lead: Mike Bopf

Evaluation Lead: Mike Bopf | ESDIS Lead: Steve Kempler

Start Date: 01-Sep-1994 | End Date: 27-Mar-1995 | Effort: 28 man months


Objective:

- Prototype selected Planning Subsystem functionality using the Delphi Toolkit initially. This prototype will provide the ability to generate a production plan.

- Determine whether Delphi is a viable software solution for the PDPS Planning problem domain.

- Determine reuse capabilities and ease of extensibility of Delphi product.

- Support Level 4 software requirements definition and clarification in the initial phase.

- Evaluate underlying Object Oriented class library


Approach:

The following approach/schedule will be used for this prototype:

- Create a model of the resources at a DAAC (computers, CPUs, disk, etc) and be able to group them into "processing strings" and classes with similar attributes;

- Incorporate a generic system for handling data dependencies;

- Specify classes of processing such as standard processing, reprocessing, and on demand processing;

- Specify strategies and rules for processing or dedication of certain processes to machines or strings;

- GUI to demo user interfaces for schedule/plan creation, modification activation, etc. and GUI to update planning database and error messages;

- Generate production plan based on strategies, resources, process profiles, and Data Availability Schedules;

Schedule

Phase l (due 12/16 - completed)

Phase ll (due 12/16)

Phase lll (due post PDR)


Evaluation Method:

- The success of the prototype will be checked at the end of each phase. Each phase is contingent upon a successful completion of the previous phase

- The results of this prototype will be documented in ???


Monthly Update:

N/A


Key Events:

Prototype was demonstrated to ESDIS on January 6, 1995


Results:

3/24/95

We have completed the current phase of the Planning Prototype which emphasized reporting and DBMS interfacing. We successfully translated a plan into a report database table which can than be queried. The Sybase tool used to do this was text-based, so we are working on changing this interface slightly to add a report button with surprisingly little effort. We also created a Builder Xcessory GUI to prototype a Planning User interface, and hooked this into Delphi via a command-line API. We will be demoing the prototype soon.

The objectives of the next phase are currently under construction.

2/13/95

The current effort in the Planning Prototype emphasizes the user interface and database connectivity. Delphi does not have a generic report capability, which is perceived as an important requirement. Instead, we are investigating it's compatibility with Sybase, and once the flat data tables are converted into database tables, we will use Sybase reports for what we need. Additionally, we are using Builder Xcessory (a GUI builder) to mock up our concept of a "Create Plan" user interface, and link this into the Delphi plan creation.

1/5/95

We completed the first build of the second phase of the Planning prototype and are about to demo this to NASA PDPS. We made extensions to the prototype by using predicted multiple downloads of L0 and ancillary data. We also added capability to change resources on the fly, schedule resource outages, and use data tables similar to those that would be manipulated by the DAAC staff.

11/7/94

The main goal and objective of the prototype is to determine the feasibility of using the FOS Planning and Scheduling libraries referred to as Delphi (also called HCL, but these are at a lower level) in the PDPS Planning subsystem. This phase created a simplified version of the planning system (emphasizing standard production) that is based on the Langley DAAC hardware and CERES data products. The resource model was easier to generate than anticipated due to the generic method used by Delphi to model resources. The second phase will extend to the PDR time frame, and will begin to incorporate more complicated planning strategies, add in reprocessing and On Demand jobs, and include MISR and MOPITT data products.

We are currently working to realistically prototype how the data tables that drive our system should be formulated, and how the "planning algorithm" seems to be substantially different from the ones used in FOS. We are also working to add the concept of resource "strings" to the resource model, which will allow for the logical grouping of any computers and disks.


Documents:

No documents were produced. This prototype was closed via a demo to the customer.


Key Risks:

T-7 Database Management Systems



Planning and Scheduling Study

Type: study | Status: rejected | Category: Engineering

Release: Release A | Sub-System: N/A | Organization: N/A

Purpose: risk mitigation

Principle Investigator: N/A | Lead: Y, Sastry/G. Forman

Evaluation Lead: N/A | ESDIS Lead: N/A

Start Date: N/A | End Date: N/A | Effort: 6 man months


Objective:

- Resolution of SDPS/SCSMS and FOS/CSMS Planning & Scheduling Issues.

- HCL Trial Use

- FOS engine integration over CORBA (TBD in CSS)

- MSS P&S Application Prototyping


Approach:

N/A


Evaluation Method:

N/A


Monthly Update:

July 1995

Study was rejected due to PDPS change in planning implementation.


Key Events:

N/A


Results:

N/A


Documents:

N/A


Key Risks:

N/A



Production Topologies

Type: study | Status: in-progress | Category: Engineering

Release: Release A | Sub-System: S-DPS | Organization: SCDO

Purpose: requirement clarification

Principle Investigator: Narayan Prasad | Lead: Narayan Prasad

Evaluation Lead: N/A | ESDIS Lead: N/A

Start Date: 11-Jan-1994 | End Date: N/A | Effort: 2 man months


Objective:

Study to evaluate data processing pooling alternatives to maximize throughput and optimize resource utilization (disk space, network bandwidth, etc.)


Approach:

Using ECS system performance model and AHWGP baseline, evaluate a number of problems pertaining to disk capacity, etc.


Evaluation Method:

N/A


Monthly Update:

January 1996

Work on this prototype is transferred to Release B. Due to state of flux on the choice of processing hardware, specifically the network Hardware/Software and the choice staging disk, it is premature to arrive at any definite decision on the choice of any one of the production topologies for prototyping. The decision on production topologies is pending a white paper on hardware which is presently being written.

August 1995 - Analysis of the first phase continued with results being drafted. This study will be transitioned over to the Release B group during phase 2. Please see new results listed below for this time frame.

July, 1995 - Analysis with systems performance model complete. Writing in progress.


Key Events:

Release A CDR.


Results:

August 31, 1995:

In the first part of this trade-off study analysis issued at PDR (Ref number: 440-TP-006-001), four cluster optimization alternatives were identified to do production processing.

In the second phase of this trade study, a static and a more detailed dynamic analysis of AHWGP data is performed for the third quarter of 1999 (Release B/C) time period for the first optimization alternative, namely "one instrument's products per cluster". Four DAACs (LaRC, GSFC, EDC and MSFC) have been chosen for this study. The January 1995 AHWGP baseline is used as input for both static and dynamic analyses. The ECS System Performance Model is used to dynamically simulate processing. The LaRC DAAC will process CERES, MISR and MOPITT instrument data. Because CERES and MISR have large processing requirements and I/O loads, and together with MOPITT have external data dependencies (e.g. MODIS products), they will provide insight into the architectural constraints, if any for the production topologies considered. Similarly MODIS at GSFC will provide insight into the kind of topologies required at that site. The ASTER and MODIS (L3 processing was not included) processing at EDC is also evaluated based on the data provided by the AHWGP. Because of the small processing requirements for the LIS instrument, it will not be necessary to consider various production topologies at MSFC. Nonetheless, both a static and dynamic analyses is performed to understand capacity requirements.

Due to limitations with the current version of the ECS Systems Performance Model in simulating all cluster optimization alternatives, only one production topology is analyzed dynamically. Therefore, recommendations to the most appropriate topology at each site is deferred until further analysis with more topologies is performed.

Early Phase 1 Results :

Results are outlined in tech paper 440-TP-006-PDR version 001.


Documents:

Production Topologies. PDR copy on EDHS. CDR update to be presented.


Key Risks:

N/A



Science Software Execution Prototype

Type: prototype | Status: completed | Category: Engineering

Release: Release A | Sub-System: S-DPS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: Narayan Prasad | Lead: Narayan Prasad

Evaluation Lead: N/A | ESDIS Lead: N/A

Start Date: 27-Mar-1995 | End Date: 31-August-1995 | Effort: 24 man months


Objective:

- This ongoing effort will provide the hardware and software environment, which includes AI&T tools for science software integration with the DAAC SDP toolkit. It will also evaluate the various processing technology alternatives (DCE,SMP, DMP MPP, etc.) and their suitability for science data processing. it will also provide feedback to the science community about the use of these technologies.

- Evaluate processing technology alternatives (DCE,SMP,DMP,MPP, etc.)

- Analyze performance of candidate architectures to relate to algorithm processing requirements (determine if required processing rates can be met using a processing alternative)

- Identify toolkit performance/accuracy issues, if any, provide feedback to the instrument teams as well as the toolkit developers

- Algorithm Analysis - science algorithms will be brought in and analyzed for their data and resource requirements, and processing approach


Approach:

The following schedule/approach will be used for this prototype :

- The ECS STL distributed/parallel testbed, selected vendor hardware, and resources available at selected NASA HPCC sites will be used to develop this prototype.

- The proposed approach is to acquire as many Fortran/C algorithms, analyze them, match them to a processing alternative, and set up benchmark suites to meet the objectives to listed above.

- The process of these activities will be communicated to ECSDIS via reports and lab demos

- AVHRR/Land Pathfinder - sequential prototype (control runs) on various testbed platforms (Feb/Mar 1994)

- ERBE Inversion Subsystem code from LaRC - prototype for sequential run on SUN workstations (Apr/May 1994)

- Distributed computing of AVHRR/Land Pathfinder algorithm (initialization and navigation code) using OFSF/DCE on distributed set of workstations (Jun 1994)

- High Performance Fortran Forum (HPFF) Purdue set benchmarks. Sequential and parallel processing (SMP) runs to understand code structures for parallel processors (July/Aug 1994)

- ERBE Inversions Subsystem prototype of distributed parallel processing on workstation platforms - code unsuitable for parallel processing without major restructuring. Performance runs obtained (Jul/Aug 1994)

- ScanSAR benchmark evaluation (ongoing)

- Acquire MPP algorithms form DOA (when available)

- The process control. memory management, and I/O tools from the SDP (PGS) toolkit will be wrapped around at least the following two algorithms to study performance and other issues

- SSM/I precipitation rate algorithm (sequential) (Oct 1994)

- AVHRR/Land Pathfinder algorithm (sequential) (Oct 1994)

- Using code snippets, test other important tools not used by the above algorithms (completion TBD)


Evaluation Method:

- Use ECS STL distributed/parallel testbed machines vendor loaned hardware, selected HPCC resources.


Monthly Update:

August 1995 - Prototype work and analysis was completed at Release A CDR. Results from the last phase are listed under Results below.

July, 1995 - Prototype complete. Report to be written.


Key Events:

CDR poster session/demonstration.


Results:

August 1995:

Work done in the last phase:

Fortran 90 and HPF Prototyping at ECS STL - Lessons Learned

Goals:

Test F90 compilers on F77 code

Study F77 conversion to F90

Study portability of F90 code

Study performance gain of F90 over F77

Study Fortran 90, HPF and parallel processing results :

A) Fortran 90, because of many vendor specific implementations can introduce complexities during Science Software Integration & Test.

B) F77 code may not be all compatible on a F90 compiler due to misinterpretation of F77 extensions.

C) HDF libraries in its present form may not be suitable for parallel software implementation, especially in a Distributed Memory environment. Most parallel software development tools are based on the SPMD model. Wrappers are required around I/O calls to the HDF library to prevent parallel calls to the HDF libraries. Such an approach can offset any performance gains due to parallelism.

D) Currently, only subset HPF (only a subset of the HPF constructs are implemented) compilers are available. Parallel software development using these tools have been encouraging.

July, 1995

Pathfinder SSM/I algorithm translated to Fortran 90 using pghpf, subset HPF directives were inserted.

5/25/95

The SSM/I Pathfinder precipitation rate algorithm F90/HPF completed. Preliminary runs were made using multiprocessing capabilities using pghpf compiler.

4/24/95

As part of the Planning and Data Processing Prototyping at the ECS Science and Technology Laboratory, representative ECS heritage science algorithms were prototyped to study various processing paradigms like distributed computing and parallel processing. The science software were ported to many hardware platforms. Experiences and lessons learned on portability of science software are documented in a presentation package presented at the Science Software Integration and Testing Workshop on 18 April 1995 in Landover, MD.

As part of the ongoing Planning and Data Processing Subsystem Software Execution Prototype at the ECS Science and Technology Laboratory and selected Computing Center (HPCC) sites at the Jet Propulsion Laboratory (JPL) and NASA/Ames, a heritage ECS science algorithm called "SeaWinds" (from JPL) was prototyped on: a) Symmetric Multiprocessor (SMP) using the latest shared memory multiprocessing techniques, b) Workstation Cluster using the latest distributed memory multiprocessing techniques, and c) Massively Parallel Processors using parallelization tools. The objectives of this phase of prototype include demonstrating migration of parallel applications developed on SMP and Workstation cluster to MPPs, studying MPPs from a new perspective (with easier parallel software development methods at the same time maintaining portability) for Release B and beyond, determining applicability, and assessing workload criteria for maximizing performance on MPPs. The performance of SeaWinds (throughput, data distribution and I/O) on various hardware platforms under different paradigms (SGI Challenge XL, Workstation Cluster, Cray T3D and IBM SP2) are presented in a presentation package. (Presentation given on April 7, 1995 to ESDIS, JPL DAAC, DAO and SeaWinds Instrument Team).

Both of these presentations are available in the SDPS Home Page under Science Software Execution Prototype. 3/24/95

The Cray T3D and IBM SP-2 at JPL and NASA/Ames was used to study the applicability of MPPs for ECS science algorithms. Both SSM/I Precipitation rate and SeaWinds algorithms were studied and the following objectives and go determine maturity of software parallelization tools (automatic parallelizers, etc.) on the Cray T3D. CRAFT was the primary focus.

* Determine a path for the migration of applications developed on workstation cluster to the Cray T3D and IBM SP-2. Primary focus was on the level of effort, effective processor utilization, usefulness of parallization tools to aid migration to MPPs, etc.

* Study parallelization strategies using a set of problems called "Purdue Benchmarks". Running parallel benchmarks was meant to be educational to aid EOS science software developers in understanding compiler behavior.

* Study science software in a MPP environment after development on SMP and DMP/workstation cluster.

1/5/95

The SMP and DMP portions of this prototype have been completed and a presentation demo was done on 12/6/94. The Pathfinder SSM/I precipitation rate and SeaWinds algorithms have been characterized and transformed into scalable parallel algorithms using parallelization tools executed on an SMP hardware. Using DMP parallelization tools, distributed cooperative computing using workstation clusters (connected together using a high speed network like FDDI) are explored with the Pathfinder SSM/I precipitation rate algorithm.

12/94

- AVHRR/Land Pathfinder - sequential prototype (control runs) on HP, SGI, SUN, IBM RS6000 machines set up completed Feb/Mar 1994

- ERBE Inversion Subsystem Code from LaRC - prototype for sequential run on SUN workstations completed April/May 1994

- Distribute computing of AVHRR/Land Pathfinder algorithm (initialization and navigation code) using OSF/DCE on a distributed set of workstations - completed June 1994

- Sequential processing of SSM/I precipitation rate, sea ice algorithms (as control runs) completed June/July 1994

- High Performance Fortran Forum (HPFF) benchmarks obtained from Rice University. Completed sequential and parallel (isometric multiprocessor) runs to understand code for parallel processors (July/August 1994)

- Parallel processing of Pathfinder SSM/I precipitation rate algorithm on symmetric multiprocessor (SGI Challenge), performance analysis, etc. - (July/August 1994)

- ERBE Inversion Subsystem prototype of distributed parallel processing on workstation platforms - code unsuitable for parallel processing without major restructuring. Performance runs obtained (July/August 1994)

- ScanSAR benchmark evaluation (ongoing)

- A scalable parallelization strategy (scalable from small workstation clusters to MPPs) has been implemented to a sequential form of the SeaWinds algorithm obtained from JPL.

- A symmetric Multiprocessor SGI challenge with 8 processors was used as a testbed platform to study the parallelization strategy implemented into Spited I/O as a limitation to performance, we attained speedup of nearly 4. Currently, the algorithm is being timed, excluding I/O, to gain understanding of performance of CPU intensive portions of the algorithm.

- The SDP toolkit has been embedded into the Pathfinder precipitation rate algorithm and Pathfinder AVHRR (4KM) algorithm. A report entitled "SDP Toolkit Implementation with Pathfinder Precipitation rate Algorithm" will soon be available to the science community. This report is a study of toolkit performance on an 8 processor SGI Challenge and lessons learned during the implementation. Methods to use the SDP toolkit in a parallel environment (shared memory) are outlined.

- A distributed memory parallel processing strategy is currently being applied to both SeaWinds and Pathfinder SSM/I pathfinder precipitation rate algorithm. We are studying the behavior of HDF libraries in a parallel environment. Lessons learned will be communicated to the science community in the future PDPS prototyping reports.


Documents:

"PDPS Prototyping at ECS Science and Technology Laboratory Progress Report #4" - available on the SDPS section of the EDHS (http://edhs1.gsfc.nasa.gov/)

Final report to be written. Please look to this link for more information.


Key Risks:

U4, U5, U7



Storage Technology Insertion Plan (STIP)

Type: study | Status: completed | Category: Engineering

Release: Release A | Sub-System: S-DSS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: Mark Huber | Lead: Ben Kobler

Evaluation Lead: N/A | ESDIS Lead: N/A

Start Date: N/A | End Date: N/A | Effort: 6 man months


Objective:

Perform analyses and provide periodic updates to the STIP, which is a living document that describes the various storage technologies that are available at the time of the update, as well as near future technologies. The plan analyzes how these technologies can/should be phased into the architecture over time.


Approach:

Analyze legacy plan, assess archive requirements performance, equipment.


Evaluation Method:

Alla Lake performed all analysis and design.


Monthly Update:

October, 1995 - Conclusions utilized for Release B IDR presentation preparation.

July, 1995 - Conclusions utilized for Release A CDR presentation preparation.


Key Events:

Feeds design review documentation; "living document" is constantly updated.


Results:

Presently investigating RAID 3 and 5 applicability to working storage, network attached storage implementations, high performance networks including HIPPI and Fibre-Channel, and new high performance tape drive technology.


Documents:

Storage Technology Insertion Plan white paper # 420-WP-003-001


Key Risks:

T5, T8



User Registration

Type: prototype | Status: Complete | Category: N/A

Release: Release A | Sub-System: MSS | Organization: SCDO

Purpose: functional enhancement

Principle Investigator: Matt Scher | Lead: Gary Forman

Evaluation Lead: N/A | ESDIS Lead: N/A

Start Date: 06-May-1995 | End Date: 30-Aug-1995 | Effort: 2 man months


Objective:

Implement User Interface and functionality required for an M & O operator to create an account for an authorized user, based on the request received.


Approach:

-Implement HTML form to support GUI interface for account maintenance.

Implement Sg base SGL + Schema to support data storage.

Receive account request from Client subsystem, process information provided from HTML registration form, create Sybase entry for user profile, create DCE account. Provide operator interface for entry of ECS provided information for account creation.


Evaluation Method:

Demonstration


Monthly Update:

October 95 - Demonstrated capability to receive User Account Request, parse and queue request for operator review. Present information to operator on HTML form which includes additional information provided by ECS operations, create User Profile entry into database and creates DCE account for the user. Initial capability demonstrated.

DCE account management initiated.


Key Events:

Demonstration at CDR, complete for EP-6


Results:

October 1995 - End-to-end account creation demonstrated and included in EP-6 software. Account information can be displayed from Sybase (user profile information) or through DCE administration.

Approach validated


Documents:

EP-6 Documentation


Key Risks:

N/A



Working Storage Study

Type: study | Status: completed | Category: Engineering

Release: Release A | Sub-System: S-DSS | Organization: SCDO

Purpose: requirement clarification

Principle Investigator: Mark Huber | Lead: Tom Smith

Evaluation Lead: Mark Huber | ESDIS Lead: Ben Kobler

Start Date: 01-Jan-1995 | End Date: 07-Jul-1995 | Effort: 4 man months


Objective:

Study will analyze the benefits of multi-tiered configuration of working storage that is non-hierarchical. The study will develop baseline sizing estimates for staging and caching storage, and analyze strategies for preemptive staging/intelligent purging.


Approach:

Outline, do research, do analysis, write document.


Evaluation Method:

Peer review.


Monthly Update:

October 1995--internal review of Working Storage Study underway.


Key Events:

Feeds CDR


Results:

Results of report incorporated in Release A DID 305 (CD-305-008-001).

The capacity of the working storage disk for release A use was determined on the processing subsystems predicted needs for data pre-staging and production volume and patterns, staging needs for the electronic distribution, and the minimum FSMS staging requirement. The Processing Subsystem activity assumptions were based on the Performance Modeling group's dynamic analysis of the AHWGP data for epoch e. For sizing of the distribution disk volume AHWGP data for epoch e was used of the size of the largest data granule for TRMM products.

Increasing the size of working storage to use as cache will reduce lower tier performance requirements; therefore reducing the number of accesses to the deep archive.


Documents:

Release A DID 305 (CD-305-008-001).


Key Risks:

N/A




Release B


Advanced Network Storage Prototype

Type: prototype | Status: In Progress | Category: Engineering

Release: Release B | Sub-System: S-DSS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: Judy Smith | Lead: Sonlinh Phuvan

Evaluation Lead: Tom Smith | ESDIS Lead: Ben Kobler

Start Date: 8/95 | End Date: 4/96 | Effort: 8 man months


Objective:

Follow-on to Network Attached Storage Prototype. Evaluated the economic feasibility of using network attached storage. Trade off analysis was performed between network attached storage vs. host attached storage. Network attached storage implementation strategies are being investigated.


Approach:

Performing preliminary cost/benefit analysis with EDS to determine efficacy of proposed approach. Performance trade off analysis of network attached storage implementation will be investigated.


Evaluation Method:

Peer and government review


Monthly Update:

January 1996 - Two network storage implementations have been identified: HIPPI and Fibre-Channel with Bulk Data Service (BDS), and shared two-port disk with BDS. Impact study of those two implementation options is being performed.

November 1995 - Heterogeneous solutions costed out and in review.

October 1995 -- Preliminary cost/benefit analysis with EDC started.

August 1995 - Continued dialogue with multiple vendors. Working evaluation/teaming agreements.

July, 1995 - Working with venders to better define the approach and extent of this prototype


Key Events:

Release B CDR


Results:

In Progress;


Documents:

In Progress;


Key Risks:

T5



AutoSys Scalability

Type: Prototype | Status: In-Progress | Category: Engineering

Release: Release B | Sub-System: S-DPS | Organization: SCDO

Purpose: Risk Mitigation

Principle Investigator: Doug Sims | Lead: Doug Sims

Evaluation Lead: Doug Sims | ESDIS Lead: Steve Kempler

Start Date: 2-Jan-1996 | End Date: 10-Mar-1996 | Effort: 2.5 man months


Objective:

Evaluate AutoSys throughput performance with large numbers (80-300K) of job definitions scheduled in 24 hours.


Approach:

Using the Queuing Server machine in the mini-DAAC and eight client machines to simulate science processors at GSFC, see how AutoSys handles the scheduling of large numbers of DPRS/job boxes. A simulator has been written to create the job boxes and constituent jobs. Numbers from the modeling group will be used to arrive at a realistic mix of sleep jobs that will simulate executing PGEs. Vendor and ECS staff will participate in tuning Sybase if necessary.


Evaluation Method:

Will use the AutoSys Autorep utility to capture throughput data. Throughput graphs will be created that show throughput as a function of number of job definitions and of number of simultaneous jobs scheduled. May use the Sybase monitoring tool, DBVision to collect Sybase performance metrics.


Monthly Update:

March 1, 1996 Implementation of the prototype is delayed pending installation of hardware and software in the mini-DAAC to support concurrent running of the prototype along with I&T for Release A.


Key Events:

N/A


Results:

N/A


Documents:

N/A


Key Risks:

N/A



Client Database Support

Type: prototype | Status: completed | Category: Technology

Release: Release B | Sub-System: CLS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: Lynne Case | Lead: Lynne Case

Evaluation Lead: Kevin Limperos | ESDIS Lead: Ken McDonald

Start Date: 30-Jun-1995 | End Date: 2-Jul-1995 | Effort: 2 man months


Objective:

The client subsystem needs a local DBMS to provide a variety of functions such as storing and searching temporary results, logging and querying session transactions, etc. Objectives include:

1. Evaluate publicly available DBMSs.

2. Develop prototype client functions with one or more of these DBMSs.


Approach:

1. Create evaluation criteria based on functions that must be supported based on input from the client subsystem developers.

2. Review the Internet FAQ of public DBMSs and select viable ones to investigate further. Investigate these options and install those that seem promising. Preferably, the chosen candidates will interface well with C++.

3. Select candidate applications to build to cover the evaluation criteria and implement those functions with the candidate DBMSs.

4. Rank the DBMSs and publish results.


Evaluation Method:

Client subsystem developers will review the final report and evaluate the applications written.


Monthly Update:

July 1995

Prototype was completed in June and the results have been published in the following document: ECS Client Database Evaluation EDHS Document # 222-TP-008-001


Key Events:

N/A


Results:

July 1995

Prototype has been completed. A shareware product called mSQL (miniSQL) was selected from the list of packages evaluated. The report documents the findings of the evaluation and determining factors of why mSQL was selected.


Documents:

ECS Client Database Evaluation: EDHS Document # 222-TP-008-001

Selected shareware database called mSQL (mini-SQL). A contract has been negotiated to support for EP process with hooks to support full Release B operations if necessary. This would reside at the client at no cost to the end user.


Key Risks:

Need to have DBMS functionality with no cost to the user.

T-7: Data Base Management Systems



DAR Prototype Phase 2

Type: Prototype | Status: Proposed | Category: Engineering

Release: Release B | Sub-System: S-CLS | Organization: SCDO

Purpose: Functional Enhancement

Principle Investigator: John Ujhazy | Lead: Charles Li

Evaluation Lead: John Ujhazy | ESDIS Lead: Ken McDonald

Start Date: March 1996 | End Date: June 1996 | Effort: 6 man months


Objective:

1. Investigate the requirements of the ASTER DAR Client as well as implement a set of these requirements.

2. Work with the ASTER science team to refine the requirements, functionality, and the look and feel of the interface.

3. Validate functionality of DAR Client against the Japanese GDS interface API specifications.

4. Develop a well-featured DAR Client for evaluation in EP7.


Approach:

1. Develop a detailed schedule for DAR development, including user evaluation milestones and development of requirements.

2. Continue prototyping work using existing ASTER DAR prototype mockups, requirements, and other products of the first phase of DAR prototyping. Develp a file-based backend for the phase 1 prototype GUIs.

3. Develop scenarios for DAR interface tool operations as well as interactions with other Client tools (ESST, DPR tool, etc.).

4. Evaluate the STK mapping software against requirements to determine what functionality needs to be added to support the DAR requirements as well as specify how this can be done.

5. Continue with iterations of DAR Client prototype ( including supporting windows that contain the maps, timelines as well as any dialog boxes that may be popped up during operations.) and review these with the ASTER science team, noting corrections that must be made.

6. Evaluate the ECS FOS timeline software against requirements to determine what functionality needs to be added to support the DAR requirements, as well as specify how this can be done.

7. Compare DAR tool functionality being implemented against functionality offered by the ASTER GDS APIs.

8. If the evaluated timeline and mapping modules are sufficiently robust to support further development, make DAR interface tool available for evaluation in EP7 (delivered DAR interface tool to include FOS timeline and STK mapping modules integrated with motif GUI screens). The DAR prototype would be available as a standalone prototype and not integrated into EP7.

PERIOD OF PERFORMANCE WILL BE MARCH TO JULY 1996


Evaluation Method:

The prototype will be periodically evaluated by the ASTER science team during the period of performance as defined in the schedule. The client subsystem developers will evaluate the code for inclusion in EP7. The interface will be evaluated by science users in EP7.


Monthly Update:

February 1996

This prototype has just been proposed. Schedule and details for the prototype activities are currently being worked out.


Key Events:

Turnover of prototype to EP7


Results:

N/A


Documents:

N/A


Key Risks:

N/A



DAR Prototype

Type: prototype | Status: in-progress | Category: Engineering

Release: Release B | Sub-System: S-CLS | Organization: SCDO

Purpose: requirement clarification

Principle Investigator: John Ujhazy | Lead: Charles Li

Evaluation Lead: John Ujhazy | ESDIS Lead: Ken McDonald

Start Date: 21-Jun-1995 | End Date: 08-Dec-1995 | Effort: 5 man months


Objective:

1. Investigate the requirements of the ASTER Data Acquisition Requests (DARs) as well as implement some of these requirements.

2. Work with the ASTER science team to validate the requirements, functionality, and the look and feel of the interface.

3. Get feedback on the interface in prototype workshop 2 (PW2).


Approach:

0. Review the evaluation done by the client subsystem team of the existing ASTER DAR prototype.

1. Work with the ASTER science team to define the objectives of the prototype. This will involve reviewing the requirements as the ASTER science team sees them in respect to the ECS Level 3 and 4 requirements. Prioritize these requirements and determine those that will be investigated and developed in the allotted time frame of the prototype.

2. Evaluate the mapping software selected for EP6 to determine what functionality needs to be added to support the DAR requirements as well as specify how this can be done (Design).

3. Create mockups of the supporting windows (i.e. the windows that contain the maps as well as any dialog boxes that may be popped up during operations.). Review these with the ASTER science team and note corrections that must be made.

4. Install the DAR DB and DBMS that is being created by the ASTER science team in conjunction with ASU (Arizona State University).

5. Develop the functions defined in the objectives using the "mocked" up screens, the mapping package, and the DAR DB.

6. Periodically review progress with ASTER science team.

7. Integrate with PW2.

PERIOD OF PERFORMANCE WILL BE JUNE TO NOVEMBER 1995


Evaluation Method:

The interface will be evaluated by science users in PW2 as well as during the process by the ASTER science team. The client subsystem developers will evaluate the code for inclusion in an increment.


Monthly Update:

February 1996

The prototype incorporated ASTER science team comments from prior iterations. Work on the prototype continued with the addition of the following features:

A file oriented back end was added to allow the capability to save DARs to disk

A rudimentary capability to search for DARs by key attributes

A capability for retrieval of DARs into the DAR tool.

The Phase 1 DAR prototype is completed. Evaluation of existing mapping and timeline modules has revealed that they do not have the features necessary to support DAR tool requirements. Prototype work will be continued under DAR Prototype Phase 2, which is documented separately. The new prototype supports objectives which allow for further evaluation of timeline and mapping modules for the DAR tool.

January 1996

We had a teleconference with JPL ASTER science team to review the DAR initial objectives. We concluded that most of the initial objectives were met except that DAR DB was not available for back end implementation. We took the action to deliver the current version of DAR to JPL on Feb. 9 and worked with them to make it to work at JPL for comments.

We started to work on a DAR database and will implement minimal saving and retrieving functions on a plain file bases. It is expected to deliver this version of DAR by the end of Feb.

We concluded that IDL map functionality would not meet the FRMO of DAR and we will not put further efforts on IDL. We have arranged with AGI to start to evaluate STK/PL map utilities from March 1 to April 1.

Our prototype manager had worked out a new schedule to further develop DAR. The schedule will be sent to ASTER science team.

Dec 1995

We developed a map display utility using IDL to explore its feasibility for PW2. The IDL provides a map database(CIA world data bank-II) and satisfy some basics of FRMO. Different kinds of map projections, zooming and area selection are implemented. This will be a demo during PW2 for comments. Due to its graphic limitation, we would like to use other COTS, for instance, STK/PL after PW2.

We have discussed with ASU about the DAR database to be used by DAR prototyping. As a result, we need to create /or define a DAR DB for the DAR prototyping at Hughes. As an alternative, we may use plain file to handle it instead.

We further implemented some comments from the end uses to the DAR GUI interface.

We initiated a process for EDS to negotiate with Analytical Graphics, INC for an evaluation package of STK/PL.

Nov 1995

Feedbacks from the science teams and further improvements on the mockups are incorporated into the DAR GUI interface. We evaluated the map display and manipulation options further.

The current EP6 spatial selection screen is ruled out due to its lack of map database and primitive graphics manipulations. This package is derived from the Langley IMS.

We created a map screen using IDL to explore its feasibility and we found that IDL can provide a map database(CIA world data bank-II) and satisfiy some basics of FRMO.

We further evaluated the STK/PL from Analytical Graphics, INC. We had two meetings with both their business and technical personnel. The STK/PL will meet the FRMO from a technical perspective,but it needs further management consideration due to its cost factor.

The current tentative map display software candidate is STK/PL. We will pursue this option if we can negotiate a resonable contract with Analytical Graphics, INC.

Oct 1995

Mockups of the query and data entry screens were shown to Gary Geller. These mockups will be shown to other ASTER science team members to get feedback.

Sept 1995

Evaluations of map display and manipulation options were evaluated. The current EP6 spatial selection screen was used as one option (derived from the Langley IMS). Other options evaluated were: IDL (Interactive Data Language), ESA's UIT (User Interface Terminal) Map features, and STK (Satellite Toolkit). These options were evaluated based on their ability to support the features needed over and above the Earth Science Search Tool functions, the resources needed to add the enhancements, and the commercial licensing restrictions. No decision has been made on which of these options will be used in the prototype.

August 1995

The objectives were reviewed with Gary Geller. Gary relayed the concerns of the entire ASTER team. Primarily there was a concern about the objectives being over ambitious. A decision was made that the ASTER team should prioritize the objectives so that if all objectives cannot be met, the most important will be kept. The decision has been made to use the EP6 Earth Science Search Tool user interface as a template for the HMI since the functionality's are similar and will give the user a common look and feel between searching for data and searching for DARs.

July 1995

Defined objective in prototype; distributed to ASTER Science office at JPL. There is a July 24, 1995 meeting for feedback.


Key Events:

PW2 - CDR


Results:

N/A


Documents:

N/A


Key Risks:

N/A



DCE Secured Web Prototype

Type: prototype | Status: Completed | Category: Technology

Release: Release B | Sub-System: C-CSS | Organization: SCDO

Purpose: functional enhancement

Principle Investigator: Shabahat Husain | Lead: Loretta Wilder

Evaluation Lead: Shabahat Husain | ESDIS Lead: Hal Folts

Start Date: 10-Jul-1995 | End Date: 22-Nov-1995 | Effort: 6 man months


Objective:

The purpose of the Distributed Computing Environment (DCE) secured Web prototyping is to integrate DCE with the web technology to satisfy Release B ECS security requirements.


Approach:

1. Identify ECS requirements and select candidate implementation(s) based on time and resource constraints of the prototyping effort.

2. Explore the impact on subsystems with a coordinated effort of affected subsystem teams. This would include impact on subsystems' product, development tools, schedule, etc..

3. Design a detailed prototyping plan

4. Build/implement the selected product in a constructed environment of selected hosts and network.

5. Evaluate the product using the criteria above (where applicable).

6. Add specific ECS subsystem components to expand the environment to all affected subsystems. Complete the evaluation process.

7. Generate prototyping evaluation report, risks, conclusion, and recommendation.


Evaluation Method:

The World wide web is becoming ubiquitous. Enterprises are discovering that Web technology can help to communicate internally as well as externally. The prototype will include several topics such as Web security requirements, DCE security for the Web, Web applications for Client Interoperability and Data Management (CIDM) team and other groups.


Monthly Update:

November 1995 - The DCE web prototype is completed. Recommendations and prototyping results are described in a white paper entitled "Secured Web Prototype Phase 1" document.

October 1995 - We have updated the software and configured it to run within the ECS environment. We have tested the functionality which is currently being documented in a white paper. The prototype was completed with a demo at IDR to the board panel and ESDIS personnel. The white paper will include different features of the prototype as well as our recommendations for the secured web server.

September 1995 - We have downloaded the OSF's web server and browser software from the Internet. Our current architecture is a Sun solaris using DCE 1.0.3. We will be running Open Software Foundation (OSF's) Hypertext Transfer Protocol (HTTP) demon and testing this server with different browsers. The browsers will be tested within the DCE-environment and using a non-DCE environment, by doing this we will be able to verify OSF's gateway for non-DCE users and the tunneling toolkit for DCE-based users.

August 1995 - We have selected a candidate product. We have identified requirements for the web server. We are currently developing a prototyping plan and we are currently exploring the impact on other subsystems using the web technology.

July, 1995 - Scoped the project for requirements; Looked at COTS availability; In process of putting together codes; Working with research organizations who are doing similar work.


Key Events:

Release B IDR


Results:

The DCE Web prototype was analyzed and implemented as outlined in the prototype plan. The major features demonstrated at IDR included 1)authentication 2)authorization 3)location dependency 4)capability with existing web servers and browsers and 5) the ease of use.

The results of this prototype demonstrated that by using a DCE web server, the integrity of the ECS data would be maintained. Due to time constraints, CSS did not integrate the web server with other ECS; however, the above functionality and concepts were proven. The server was able to authenticate users that used a DCE aware browser. The server was also able to authorize each request type whether the request was a standard HTTP or DCE-HTTP. This was done by setting the ACL permissions for each document registered on the server. While using a DCE capable browser, the user did not have to remember or know the physical location of the web server or documents registered to it. The directory naming services automatically performed a look-up for the server and the specified document(s). The web server also proved to be quite compatible with existing browsers and servers. CSS demonstrated this by using a DCE aware browser to connect to existing servers that were not running over DCE. The prototype also demonstrated the ease of using a DCE capable server and browser. By using a server and a browser that inherits the features that are offered through DCE it provides a painless and transparent interface to the user.

Although the prototype was a success, this product is not recommended because it was based on a proof of concept (generated by OSF) and also the web technology is moving rapidly. This product has already had some re-work and is currently being offered through one of OSF ATOs. CSS does not recommend this product as a solution for the web server. CSS is hoping by middle of the year there will exist a COTS package that incorporates the DCE functionality with the web. CSS feels that the market is heading in this direction and would not hinder the CSS schedule for providing a COTS solution.


Documents:

White Paper, Communications Subsystem (CSS) Design Document


Key Risks:

N/A



DIM/LIM COTS Prototype

Type: Prototype | Status: In-Progress | Category: Engineering

Release: Release B | Sub-System: F-ANA | Organization: SCDO

Purpose: COTS technology evaluation

Principle Investigator: Mike Daily | Lead: Sreedhar Muppalla

Evaluation Lead: Lynne Case | ESDIS Lead:

Start Date: Feb 24, 1996 | End Date: May 15, 1996 | Effort: 6.0 man months


Objective:

Establish technical feasibility of using COTS software for key functions.

Provide prototype code for integrating candidate COTS with ECS architecture.

Develop and test data dictionary update procedures supporting adding new provider(s)

Test performance and other scalability measures


Approach:

The following schedule/approach will be used:

Selection of product for evaluation (3/1)

Determine primary areas of COTS functionality (3/1-15)

Implement Phase I prototype for CDR demonstration (3/15-4/15)

Demonstrate at CDR (4/15-20)

Implement Phase II prototype, including rudimentary integration (4/20-5/20)

Recommend COTS insertion strategy


Evaluation Method:


Monthly Update:


Key Events:


Results:


Documents:


Key Risks:



Data Compression Prototype

Type: prototype | Status: proposed | Category: Engineering

Release: Release B | Sub-System: S-DSS | Organization: N/A

Purpose: risk mitigation

Principle Investigator: Mark Huber | Lead: Sonlinh Phuvan

Evaluation Lead: Mark Huber | ESDIS Lead: Ben Kobler

Start Date: 7/95 | End Date: 5/96 | Effort: N/A man months


Objective:

Assess applicability of data compression technologies to different ECS architectural areas.


Approach:

Perform and analyze data compression benchmarks to evaluate data compression algorithm, and processor loading.


Evaluation Method:

Work in progress to further detail these categories.


Monthly Update:

November 1995 - White Paper in Review, Data Compression Prototype being planned.

October, 1995 - Data Compression White Paper Update.

July, 1995 - Reassessing the data compression technologies plan; working out schedule.

Feb, 1996 - Data compression policy for dataserver has been formulated; undergoing internal review.


Key Events:

Release B CDR


Results:

Work in progress to further detail these categories.


Documents:

Work in progress to further detail these categories.


Key Risks:

T5, T8



Data Management Schema Maintenance Prototype

Type: prototype | Status: in-progress | Category: Engineering

Release: Release B | Sub-System: S-DMS | Organization: SCDO

Purpose: requirement clarification

Principle Investigator: Lynne Case | Lead: Estelle Westbury

Evaluation Lead: Sreedhar Muppalla | ESDIS Lead: Mike Moore

Start Date: 10-Jul-1995 | End Date: 25-Mar-1996 | Effort: 7 man months


Objective:

1. Define the security strategy for the data management subsystem applications for authorizing users to create or update schema information.

2. Develop a prototype model of how his interacts with the CSMS provided APIs.

3. Build a prototype of the protocol and language to be used when accepting requests from the data server to create or update the schema.


Approach:

1. Use existing data dictionary prototype and enhance it to include creation and update services with authorization based in CSMS supplied APIs. This initial version will not include the "final" protocol and language but will be a test of the integration with the CSMS API.

2. Construct a test driver HMI to build different "messages" to be sent to the data dictionary service. This test HMI is for easy creation of messages and for testing integration of client applications into this new environment.

3. Define protocol, language, and required information involved in the transfer of the schema information.

4. Update the existing services to support the language, protocol, and information and to populate the data dictionary database.

5. Test with the HMI..

PERIOD OF PERFORMANCE July 1995 - March 25, 1996


Evaluation Method:

DMS developers to review code and methods used.


Monthly Update:

Feb 1996

Completed integration of CSS and DSS libraries in prototype. This integration took close to siz weeks to complete. Some of the reasons were lack of build experience in a Unix environment on my part, conflicts between versions of OODCE and RogueWave and finally the necessary use of some common libraries apparently unused by either of the two subsytems being integrated.

Jan 1996

Defined protocol for requests from the Data Server. Integration of CSS and DSS libraries into prototype.

Dec 1995

Began coding of prototype, incorporating CSS Security and DSS GlParameter libraries.

Nov 1995

Defined the security strategy for the data management subsystem applications based on the CSMS Security requirements in 305-CD-028-001. Began validation of current Data Dictionary prototype.

Oct 1995

Met with Data Server developers to discuss the interaction between the science data server and the data dictionary service. A draft message format using the GlParameterList structure has been developed. This message format has to be reviewed and coordinated with the Data Server developers.

Sept 1995

Worked on the interface from the Data Server to the DDICT service. Defined the internal update functions and the classes necessary to support this function.

August 1995

Added Schema maintenance operations to the EP6 data dictionary service object model. Working on the objects to insert, update, and delete data from the data dictionary service.

July 1995

Evaluated CSMS libraries for adding access control list functions to the Data Dictionary Service Operations.


Key Events:

Release B CDR


Results:

N/A


Documents:

N/A


Key Risks:

N/A



Data Processing Request Prototype

Type: prototype | Status: In Progress | Category: Engineering

Release: Release B | Sub-System: S-CLS | Organization: SCDO

Purpose: requirement clarification

Principle Investigator: John Ujhazy | Lead: John Ujhazy

Evaluation Lead: Kevin Limperos | ESDIS Lead: Mike Moore

Start Date: 01-Dec-1995 | End Date: 30-Apr-1996 | Effort: N/A man months


Objective:

1. Investigate the requirements for DPRs, including overlapping functionality between the Processing CI and the Client CI.

2. Implement a select set of the requirements.

3. Work with selected instrument teams or scientists to validate the requirements and the functionality of the interface.

4. Obtain feedback on the interface in the TBS timeframe.


Approach:

1. Review DPR requirements with engineers from Processing CI to determine degree of overlapping functionality.

2. Identify applicable instruments to work with as well as the appropriate instrument team members and scientists.

3. Work with science community to define the objectives of the prototype. In addition to the internal objective of flushing out interface issues.

4. Work with Processing CI engineers to determine how to utilize the valids and rules scripts associated with PGEs in GUI screens (design).

5. Create mockups of the supporting screens, including dialog boxes.

6. Review mockups with science community and note corrections that must be made.

7. Provide functionality for the mockups, with focus on dynamically handling user supplied parameters for the DPR, and how PGE valids and rule scripts are utilized for the processing.

8. Periodically review progress with the "prototype advisors".


Evaluation Method:

GUI mockups, scenarios, and requirements will be made available for review on a monthly basis. The ASTER Science Team is the principal evaluator at the reviews.


Monthly Update:

Feb 96: Met again with engineers from the PDPS subsystem, and jointly developed a high level description of ECS internal interfaces and data necessary for submission of DPRs. Refined the DPR submission scenario. Begain work on first iteration of DPR GUIs.

Jan 96:

Contacted the ASTER Science Team and the ASF DAAC to obtain product specifications for their on-demand products. Analyzed the ASTER product specification to isolate user provided inputs, and developed a data model for the inputs. Produced first draft of a detailed scenario for on-demand production of ASTER data. Reviewed existing L4 requirements for requirements associated with data ordering and on-demand production requests. Meet with engineers from PDPS and determined that although they have no L4 requirements detailing how they handle production requests, there seems to be considerable overlap of functionality.


Key Events:

The DPR prototype will be included in PW3.


Results:

N/A


Documents:

N/A


Key Risks:

N/A



Distributed File System Prototype

Type: prototype | Status: Closed | Category: Technology

Release: Release B | Sub-System: C-CSS | Organization: N/A

Purpose: technology assessment

Principle Investigator: Shabahat Husain | Lead: Shabahat Husain

Evaluation Lead: Shabahat Husain | ESDIS Lead: Hal Folts

Start Date: N/A | End Date: N/A | Effort: 6 man months


Objective:

Test interoperability of DFS clients and servers on different platforms. Determine status of DFS and compare with other products.


Approach:

N/A


Evaluation Method:

N/A


Monthly Update:

January 1996

The DFS Prototype is being closed. Please review the comments in the results below for an explanation.


Key Events:

CDR


Results:

January 1996

The DFS Release B prototype is being closed for the following reasons:

1. We haven't found any requirements for DFS in release B.

2. Release A DFS was completed in 1995. The concerns expressed by Release A are still valid. However a better DFS product based on DCE 1.2.l will be available at a later time. At this time reactivation of this prototype will be considered.


Documents:

N/A


Key Risks:

N/A



ESQL Prototype

Type: Prototype | Status: In-Progress | Category: Engineering

Release: Release B | Sub-System: F-ANA | Organization: SCDO

Purpose: Requirement Clarification

Principle Investigator: Mike Daily | Lead:

Evaluation Lead: | ESDIS Lead:

Start Date: 2/15/96 | End Date: 6/30/96 | Effort: 3.0 man months


Objective:

Establish technical feasibility of Earth Science Query Language per study recommendations.

Refine requirements for user interaction in client environment


Approach:

Develop ESQL syntax generator to emit recommended SQL3 dialect

Integrate syntax generation within Java Earth-science Search Tool

Develop query passing code to support execution on Illustra benchmark

Demonstrate at CDR

Refine data access interfaces to fit DIM/LIM architecture


Evaluation Method:

Provide as part of Java prototype for evaluation by EP7 tirekickers


Monthly Update:


Key Events:


Results:


Documents:


Key Risks:



Earth Science Languages and Protocols

Type: study | Status: Completed | Category: Technology

Release: Release B | Sub-System: S-DSS | Organization: SCDO

Purpose: risk mitigation

Principle Investigator: Ron Williamson | Lead: Ron Williamson

Evaluation Lead: N/A | ESDIS Lead: N/A

Start Date: N/A | End Date: N/A | Effort: 2 man months


Objective:

- Investigate the query languages and protocols that should be used for Release A (and beyond?).

- Document the current options available for protocols and languages (such as ODL from V0, SQL3 and RDA, etc.)

- Make a suggestion of protocol and languages for different parts of the system (i.e. from the client to LIMs and DIMs as well as query languages and protocols within pieces of the data server).


Approach:

The following schedule/approach will be used for this prototype:

- Document the current alternatives. Use the minutes of the protocol workshop from CEOS in Sept. as a starting point as well as work done for SDR. Look for options available in the community such as languages used in Sequioa0, HTTP, etc.

- Investigate the applicability of each of three options in relation to the different components of the architecture. Relate these options to actual ways to implement this in relationship to the CSMS infrastructure.

- Recommend a protocol and language for each SDPS subsystem that is applicable.

- This study will be performed from Nov 19, 1994 to Jan 6,1995 to support the incremental development of the data management portions delivered as part of the EPs. The results may be modified with further analysis based of PDR and CDR work for formal track development.


Evaluation Method:

- A technical paper will be published documenting the results.


Monthly Update:

October 1995 - T