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
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
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)
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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)
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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:
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