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 - This study of the Earth Science Query Language and associated
protocol options. The recomendations were documented in a white paper and in the
introduction to the Release B DID 305. The results were also briefed at the Release B
IDR.
August 1995 - This study was recently restarted in early September. It will
refocus results to Release B and C development. Look for more detailed changes
in the existing report fields during September and October.
Key Events:
White Paper Generated
Updated Release B DID 305 Overview for Query Language and Protocols
Briefed Conclusions of Study at Release B IDR
Results:
Jan 96:
This study was completed in Oct 1995 with the generation of the study White Paper and the
documentation of study results at IDR. A second phase of work which would involve
production of a prototype is being proposed as a separate work effort.
October 1995
The study recommended that a baseline be evaluated as part of the prototyping workshop
and the EP7 evaluation process and that a choice be selected by the Release B CDR. The
baseline included the use of an Illustra extended SQL to represent Earth Science Queries,
the integration of the language into the ECS Client interface, the Data Management
components, and the upper layers of the Science Data Server. The ESQL text would be
included as a text string in the DOF Query Object and passed to the search servers via
the standard Release B DOF based protocol for server sessions, requests, and result
management.
Documents:
White Paper Document Study Effort on ESQL and Protocols
DID 305 ESQL Overview
Release B IDR Briefing Charts
Key Risks:
T-2 Earth Science Data Language
Type: Prototype | Status: in progress | Category: Engineering
Release: Release B | Sub-System: S-PLS | Organization: SCDO
Purpose: risk mitigation
Principle Investigator: Mike Bopf | Lead: Mike Bopf
Evaluation Lead: Ramsey Billups | ESDIS Lead: Steve Kepler
Start Date: 1-Jan-1996 | End Date: 30-Mar-1996 | Effort: N/A man months
Objective:
Explore various Ops Concepts for inter-DAAC planning and data dependency identification.
Determine best method for display of multiple DAAC plans. Investigate potential
database replication issues at each site.
Approach:
Attempt to use Delphi OTS product, specifically the timeline display, to explore
methods of conveying inter-DAAC data dependencies to the operator. Investigate
techniques to display the multiple DAAC plans by aggregating the low-level processes of
each individual plan. Explore the possibility of using database replication or distributed
objects to solve problem.
Evaluation Method:
Verify that all necessary information is conveyed to the operator in a concise form. This
will primarily consist of timeline-based schedules and data dependency information
presented in a graphical or tabular form.
Monthly Update:
February 1996
Refined and completed the filter. Continued prototype by tring to get Delphi Timeline to
display data dependencies in a graphical form. Soon determined that there are no display
primitives available to do this. Additionally decided that the current Timeline geometry
and configuration did not lend itself well to displaying data dependencies. Also attempted
to do this via a coloring scheme, but this also proved unmanagable. We may need to
attempt a tabular, rather than a graphical display of inter-DAAC dependencies.
January 1996
Kicked off prototype. Began investigating ways to manage the display of planned jobs using
the Delphi Timeline. Delphi is part of the Hughes Class libraries and is made up of a
number of C++ class libraries that work together to do generic planning & scheduling. We
are exploring methods of modifying the Timeline display such that different sets of jobs
can be filtered out. Our current approach will be to filter out all "non-inter-DAAC" jobs
so the operations staff can view only these jobs when viewing a plan.
December 1995
This prototype will begin in January and will focus on the display aspects of presenting
large number of data-dependencies, focusing on those which are inter-DAAC dependencies.
November 1995
Planning process for this prototype has begun. The start has been delayed until 1 Jan 96
so we can leverage off the Rel. A Planning Algorithm Prototype.
October 1995
No work was done on this prototype in October.
September 1995
No work was done on the prototype in September, except for the work done by the Release A
folks, who decided against the use of the processing COTS product for planning.
August 1995
Study is planned to start on November 30, 1995.
July 1995
Study is planned to start on November 30, 1995.
Key Events:
CDR
Results:
February 1996
It was determined that Delphi has built-in mechanisms for filtering out activities and
can do so quite efficiently. It does not, however, have built-in display primitives,
such as arrows, to easily show data dependencies. It does have the ability to use colors
to highlight and distinguish the various activities, but this still isn't sufficient to
handle the complexity exhibited by ECS data dependencies.
Documents:
Lessons Learned Paper to be produced.
Key Risks:
S-7: Production and Planning for Release B
U-8: Product Dependencies
Type: Prototype | Status: In-Progress | Category: Engineering
Release: Release B | Sub-System: CLS | Organization: SCDO
Purpose: Feature enhancement
Principle Investigator: Mike Daily | Lead: Show-Fune Chen
Evaluation Lead: Jan Poston | ESDIS Lead: Ken McDonald
Start Date: 1/15/96 | End Date: 9/30/96 | Effort: 8.0 man months
Objective:
Shift client access paradigm to Web.
Establish technical feasibility of developing all significant client functions using Web-based technologies.
Demonstrate applicability of productivity tools for Java and HTML3.
Integrate alternative client features, i.e., query preview
Approach:
Using Java, develop spatial browser matching major feature of existing X-based ESST
Using advanced HTML features, develop user environment that includes movable sashes,
radio buttons, and related style-guide features
Coordinating with University of Maryland, implement selected features of their
NRA/CAN-funded user interface in Java
Implement demonstration version for use at CDR
Demonstrate at CDR
Interface with Illustra benchmark prototype
Evaluation Method:
Demonstate at CDR
Field as part of EP7
Monthly Update:
Key Events:
Shown at PW2, to good reviews
Results:
N/A
Documents:
N/A
Key Risks:
A-1 Support approach for GCDIS/UserDIS
E-1 Paradigm Changes
Type: prototype | Status: Integrated | Category: Engineering
Release: Release B | Sub-System: DMS | Organization: SCDO
Purpose: requirement clarification
Principle Investigator: Lynne Case | Lead: Rita Nathan
Evaluation Lead: Sreedhar Muppalla | ESDIS Lead: N/A
Start Date: 17-Jul-1995 | End Date: 09-Dec-1995 | Effort: 9 man months
Objective:
- Provide prototype code for the LIM to decompose queries and distribute them to
data servers based on the contents of the query and the schema held by the LIM.
- Establish the service interface for a portion of the LIM.
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 LIM and the statements of functionality. The pieces necessary for prototyping
will be pulled out and documented. The reason for this is that we probably will be
pulled out and documented. The reason for this is that we probably don't want to
focus the prototype on things like back up.
- Revise the object model. The object model will be implemented in a server using
the CSMS infrastructure pieces available.
- Develop 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 LIM and see the query plan that
is created.
- Test. The server will be tested. These are rudimentary tests just to assure
that the prototype works when giving demonstrations.
- Schedule. This prototype runs from Jan 19 to May 19. The DBMS proposed in the
DBMS evaluation will be used for this prototype.
Evaluation Method:
- The development organization will use the test drivers 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
parse incoming queries and generate sub queries to data servers.
Monthly Update:
Jan 1996
LIM has been completed and demonstrated. No report was written, but
the design has been folded into CDR.
Dec 1995
Tested and debugged the public interfaces. Integrated the public
interfaces with the LIM internal classes. Fixed the errors caused by
integration.
Nov 1995
Modified and tested the internal LIM classes. Started implementation of the
public interfaces to the LIM.
Oct. 1995
Started implementation of the internal LIM classes supporting the construction of
query plans. Debugging and testing these internal classes. Next steps include the
implementation of the public interface to the LIM. This will be worked in conjunction
with the Gateway incremental development for PW2.
Sept 1995
The internal LIM operations were solidified while the public LIM interface was being
defined for the DID 305 documents. The LIM public interface and the interface to the
Data Server will be prototyped following the 305 publication for IDR.
August 1995
Objectives defined as a query mechanism to be used in PW2 to provide multiple
data server searches, not including coincident searches. The LIM will accept
a query and send it to multiple data servers (Release A Core Data Server
prototypes). The query language will still be using the Release A mechanism
since the Earth Science Language study will not be completed until IDR of Release
B. The LIM prototype will then have to be updated with the new query language
for EP7.
July 1995
Prototype has been re-initiated and the objectives are being defined.
Key Events:
This prototype will feed into Prototype Workshop 2.
Results:
03/24/95
Evaluated how V0 IMS servers parse the V0 ODL messages to provide the V0 gateway
capabilities. Building a server that can accept both DCE RPCs and socket level
interfaces to parse V0 ODL messages and send to V1 data servers. Communications to
data servers will be over DCE RPCs.
Started looking at GSFC IMS database design. This will be used to partition data
into local "GSFC" data servers based on products. The schemas will then be merged
into a database in which the LIM can use to parse queries to these data servers.
Will also be investigating the parsing and production of ODL messages to provide V0
gateway capabilities.
Documents:
N/A
Key Risks:
U-2 Interoperability of Earth Data Models
T-7 Database Management Systems Technology
Type: Prototype | Status: Proposed | Category: Engineering
Release: Release B | Sub-System: S-MSS | Organization: SCDO
Purpose: Risk Mitigation
Principle Investigator: Alan Gary | Lead: Alex Kirn
Evaluation Lead: Alan Gary | ESDIS Lead: N/A
Start Date: 2/5/96 | End Date: 6/30/96 | Effort: 9 man months
Objective:
To demonstrate process distinction and separation between different
modes of execution, and to show that data integrity is maintain within a given
mode. This activity is required to support a proof of design concept.
Approach:
Obtain Hardware and Software resources. The development will be done on Hewlett Packard Workstations Running HPUX10.0 and HP OpenView 4.0.
Develop Mode Management Service GUI within HP OpenView.
Develop Mode Management Service Application. The Mode Management Service application will utilize OpenView APIs to interface with the OpenView GUI and the external SNMP agents.
Evaluation Method:
Demonstration:
- Show application registration within Mode specific HP OpenView session.
Investigation:
- Confirm Process Distinction is maintained between different modes and that data integrity is maintained between modes.
Monthly Update:
February
Still trying to secure the required hardware and software resources. Developed a preliminary design to support this activity.
January
Trying to obtain the necessary hardware and software resources to support this effort.
Key Events:
TBD
Results:
TBD
Documents:
N/A
Key Risks:
TBD
Type: study | Status: Completed | Category: Engineering
Release: Release B | Sub-System: C-MSS | Organization: SCDO
Purpose: requirement clarification
Principle Investigator: Alan Gary | Lead: Alex Kirn
Evaluation Lead: Alan Gary | ESDIS Lead: Hal Foltz
Start Date: 26-Jun-1995 | End Date: 01-Oct-1995 | Effort: 2.2 man months
Objective:
The mode management study is focused on defining operational scenarios, level-4
requirements, and to provide a high-level system architecture which will enable the
simultaneous execution of multiple software modes.
Approach:
Scenario analysis has been forwarded to the Ops Group, and requirement analysis has been
forwarded to the MSS group.
Evaluation Method:
The results of the Mode Management working group have been documented in the Mode
Management white paper. The evaluation methods included a peer review and two government
presentations. The Mode Management design approach was first briefed at the Release B
IDR and then detailed at the Ops Workshop presentation. All of the concepts presented are
fully documented in the Mode Management white paper which was also distributed to
government attendees at the Ops Workshop. Comments are being collected and design
updates continue to be incorporated into the MMWP. This is a working document that will
continue to reflect the latest Mode Management design capabilities.
Monthly Update:
December 1995
The Mode Management Working Group has completed it's mission. A Mode Management
White Paper has been generated which details the results. Keep in mind the
white paper is a working document. Therefore, all future updates will be made
directly to that document. This formally closes this activity. No future
updates to this Working Group will be made.
November 1995
Developing Mode Management White Paper
October 1995
Additional analysis and research for Mode Management White Paper
September 1995
The original goals of the mode management study have been met. Operational Scenarios
have been generated which address different activities that require mode management,
e.g., release A to release B transition, testing a data server modification without
interfering with operational activities, and operational component failure during the
simultaneous execution of a test mode. In addition, a set of level-4 requirements have
been generated and a high-level system architecture model has been developed.
August 1995
Operational scenarios encompassing some mode management issues have been
developed. Additional scenarios are being evaluated for feasibility based
upon current system design constraints (OODCE, Hardware, and COTS limitations).
An initial set of L4 requirements have been generated and are undergoing
evaluation. Mode management system architecture development has just begun.
July 1995
Working group has kicked off working on developing level 4 requirements and
operation scenarios.
Key Events:
PDR - Release B - October 1995
CDR - Release B - April 1996
Results:
February 1996
A summary of the working group findings are as follows: Process distinction
and seperation within a given mode will be achieved via the directory namespace
registration process. The DCE CDS will provide this service and it will be incorporated
at the application level through the process framework. Using this method, managed
server process will register in the namespace within the mode hierarchy in which it was
initiated. This enables clients to connect to a specific mode instance of a server.
Data integrity within a mode will be maintained in a similar fashion. It will be based
on a hierarchical directry structure where mode is used in the path. All application I/O
will be performed using the specific mode in the pathname. This will insure that an
application running in one mode will not access the data from it's counterpart running in
a different mode.
Refer to the Mode Management White Paper for more details.
December 1995
Refer to the Mode Management White Paper.
September 1995
1.1 Alternatives and Options Analyzed
Mode Management, at a software level, must ensure data integrity between different modes
of execution, enable process distinction and separation between modes, automatically
provide the controls that will ensure all shared resources (COTS, network, hardware, etc.)
handle multiple mode requests on a non-interfering basis, and enable process control and
monitoring within each mode. Many different design and implementation methods were
considered during the analysis process. The following lists some of the strategies
considered and why they were not selected, followed by the basic design method chosen:
Methods Rejected:
1. Using DCE versioning for distinguishing modes - Distributed Computing Environment
(DCE) version numbers are assigned at compilation time from within the Interface
Definition Language (IDL) definition file. This solution does not provide a dynamic
means by which to setup and initiate a new mode. While this may have served as an
adequate solution for the Release A to Release B integration, since the Release B code
could be complied using a different version number prior to delivery, it does not allow
a test activity to be configured within the same release without having to first
recompile the code.
2. Separate hardware partition, including network - This alternative is too costly, i.e.,
not feasible within the current budget.
3. Total procedural solution - This alternative relies on there being periods of no
operational support during which another activity (testing/training) could then take
place. Since some of the high-volume DAACs will be operational around the clock, this
approach is not feasible.
4. Separate DCE Cell for each new mode - The setup and administration of a new DCE cell
in support of an additional mode is too costly in both time and resources. A DCE cell
requires a minimum of three dedicated hosts.
5. Dynamic process switching between modes - This capability is not possible within OODCE. In addition, if it were, maintaining internal process states would be a nightmare at best.
Methods Chosen:
1. DCE Cell Directory Service (CDS) process registration - An object framework
incorporated into the ECS design will enable (require) each application to register it's
UUID and name into a specific DCE group within the namespace. The DCE group actually
represents the "site", "mode", and "group". Where "site" represents the geographic
location for Release A and the DCE cell for Release B; "mode" represents the software
mode of execution in which the process was initiated, e.g., ops, ts1, ts2, tr1, etc.,
and "group" represents the functional association between applications, e.g., gateway,
ingest, MSS, etc.. The "site" and "mode" are set dynamically as environment variables
at application startup, and once the application has been initiated within a given mode,
it remains in that mode for the life of the process.
2. Data partitioning will be handled at the application level - All data required to
support a given mode must be clearly defined, segregated, and duplicated prior to the
initiation of the new activity. It will be partitioned by using separate volumes or by
a hierarchical directory structure within the same volume such that all reading/writing
of data will be segregated between software modes. The application will know it's site
and mode via environment variables set at process initialization. All read/write
operations will only have access to the data within the site and mode subtree.
1.2 Analysis Summary
The original goals of the mode management study have been met. Operational Scenarios
have been generated which address different activities that require mode management,
e.g., release A to release B transition, testing a data server modification without
interfering with operational activities, and operational component failure during the
simultaneous execution of a test mode. In addition, a set of level-4 requirements have
been generated and a high-level system architecture model has been developed.
Although the original goals of the study have been reached, many new areas of research
and development have been identified. Some of these elements, due to their scope,
involve other topics of issue as well. The new areas of development are as follows:
1. An object framework needs to be developed which will be incorporated into every ECS
application as part of the system infrastructure design. This framework will provide a
uniform method for enabling process monitoring and control, data integrity, and process
separation and distinction between modes. A function this framework should also include
is to provide a uniform method for event and error handling.
2. Release A's implementation of the mode management design will be required prior to
Release A to Release B transition (at a minimum). This factor is driving the Release A
participation in the Mode Management Working Group.
3. Shared resources need to be identified within each subsystem domain. Each design
team responsible for the shared resources within their functional area will be
responsible for providing a design solution which will enable multiple mode support.
Continued involvement of the mode management working group team is required to aid and
support in the on-going development and design of these areas.
Documents:
Mode Management White Paper Draft NO9530V2. To obtain copies contact:
Alex Kirn, Hughes ECS
301-925-1127, akirn@eos.hitc.com
Please specify in the email header "Request MM White Paper copy".
Key Risks:
N/A
Type: prototype | Status: in-progress | Category: Engineering
Release: Release B | Sub-System: S-DSS | Organization: N/A
Purpose: risk mitigation
Principle Investigator: Mark Huber | Lead: Gary Newell
Evaluation Lead: Mark Huber | ESDIS Lead: Ben Kobler
Start Date: 4/95 | End Date: 8/95 | Effort: 6 man months
Objective:
1. Assess potential risks and acceptable mitigation associated with the inclusion
of Network Attached Storage technologies during SDPS/DADS implementation;
2. To assess alternative design approaches to meet requirements (e.g. data, volume,
evolvability)
Approach:
1. The approach will focus on utilizing anticipated target hardware platforms (i.e.
SMP servers) and a target network environment to evaluate specific hardware and
software approaches to archive network attached storage concepts.
2. Viable products will be reviewed and then brought into the System Test Laboratory
(STL) environment for testing using a generic test suite. Focus will be on
performance, fault tolerance, and Reliability, Maintainability, and Availability (RMA).
Evaluation Method:
Test Suites and a test plan are being developed and will be available prior to the
beginning of the evaluation.
Monthly Update:
October, 1995 - no change
September, 1995 - no change
August, 1995 - Prototype testing completed. Report in review.
July, 1995 - A new report is in draft form for internal review; Testing is completed;
The hardware is disbanded.
Key Events:
Release B IDR
Results:
October, 1995
The results have been published in a Prototype Evaluation Report, ECS document number
813-RD-012-001. This document has only recently been turned over to tech. pubs., so it
may not be quite ready for distribution yet.
5/16/95
The performance testing software that will be used to characterize the performance
of the candidate Network Attached Storage (NAS) systems has been developed. Initial
performance tests are currently being conducted on the two SGI Challenger machines
located in ECS's System Testing Laboratory (STL). The actual performance tests will
occur on an isolated six member FDDI ring over the next couple of weeks. The
performance test configurations will include an initial configuration using one of the SGI's as a file server and will be followed by sequentially substituting two NAS file server systems into the FDDI ring as file servers. Performance tests
will be made in each configuration. The two candidate NAS systems are scheduled for
delivery to the STL by no later that the week of May 22.
2/96
The study was completed in 8/95. Three network attached storage systems were evaluated:
SGI, Network Appliance Corporation (NAC) system, and Falcon Fastfile System (FFS). Under quiet network
conditions, the SGI and the NAC system functioned at about the same rates.
The Falcon Fast File system did not perform as well. Under heavily loaded conditions, the SGI
server continued to perform well, and the NAC and FFS did not perform well. Additional studies
will be reported in the Advanced Network Attached Storage study during release B activities.
Documents:
Related "Network Attached Storage Concepts & Industry Survey" document to be
finalized by 3/1/95.
The final report "Network Attached Storage Prototype", August 95, #813-RD-012-001 is
available.
Key Risks:
T5
Type: study | Status: In Progress | Category: Engineering
Release: Release B | Sub-System: S-PLS | Organization: SCDO
Purpose: functional enhancement
Principle Investigator: Will Knauss | Lead: Mike Bopf
Evaluation Lead: Ramsey Billups | ESDIS Lead: Steve Kempler
Start Date: 15-Dec-95 | End Date: 15-April-1996 | Effort: 2 man months
Objective:
Describe and evaluation the various activation and production rules required by
the Science Software and used by the AHWGP. Create a mock-up of the GUI screens
used by the operator to enter these rules. Use this tool to drive out more detailed
senarios and Ops Concepts regarding the use of rules in day-to-day operations.
Approach:
Provide an initial paper to the community describing the maximal set of activations
rules. In conjunction, create a set of mocked-up operator screens to be used to enter
these rules into the system. Present both the paper and the screens at a Production Rules
Workshop with the science developers.
Evaluation Method:
Discussion with community and review of a white paper.
Monthly Update:
February 1996
Held the Production Rules Telecon on Feb. 5. It was attended by all Rel. B instrument
teams and overall went quite well. We received a lot of feedback on a number of the
Production Rules, including some we hadn't considered. This information is currently being
incorporated into the design which will be presented at CDR. It will also be documented in
the final version of the Production Rules White Paper. We have been actively following up
specific issues raised at the telecon with individual instrument teams, and will continue
to do this.
January 1996
Received feedback from the Production Rules memo and incorporated as much as possible into
a draft version of the Production Rules White paper. A web page was set up and can be
reached via the following URL:
http://newsroom.gsfc.nasa.gov/relmgt/open/RelsB/PDPS/telecon.html
After the telecon, we will send out minutes and publish issues on the above web page in
addition to sending these out to all attendees. We will work on a final version of the
white paper once we have resolved the major issues and publish that, also.
December 1995
Upon request of the Instrument Teams, the forum for discussing Production Rules has been
changed from a traditional Workshop to a telecon. It will take place on Feb. 5 as planned.
A memo was sent out describing the Production Rules we plan to handle and requesting
feedback for incorporation into the draft white paper due out in January.
November 1995
The scope of this has been changed from a prototype to a study. The main output from this
effort will be a Production Rules White paper. A draft version of this white paper will go
out on 15 Jan. 1996, with a precursor memo to the community mid-Dec. 1996.
October 1995
The start of this prototype has been postponed until January, 1996. Release A PDPS is
developing the Planning Algorithm 11/95-12/95 and Release B wants to wait until after
this work is finished.
September 1995
An evaluation copy of CLIPS has been procured.
August 1995
No work was done on this prototype in August.
July 1995
Planning has commenced and a time frame has been set. More detail to follow.
Key Events:
Production Rules Telecon on Feb. 5, 1996;
CDR
Results:
An open dialogue with the instrument teams will be maintained to verify that all required
production rules are implemented. The final Production Rules White paper will be made
available for general review, and the design will be presented at CDR.
Documents:
Production Rules White Paper
Key Risks:
N/A
Type: Study | Status: In-Progress | Category: Technology
Release: Release B | Sub-System: S-DPS | Organization: SCDO
Purpose: Technology Assessment
Principle Investigator: Dominic Leung | Lead: Dominic Leung
Evaluation Lead: Ramsey Billups | ESDIS Lead: N/A
Start Date: January 1996 | End Date: March 1996 | Effort: 3 man months
Objective:
To evaluate different production topology approaches and select one that will be both
cost effective and efficient for Release B data processing. Included in these approaches,
are those proposed in a Release A trade-study on the subject: (i) one instrument's
product per cluster, (ii) one instrument's product per cluster except for selected
products major processing resources, (iii) multiple instruments' products on any cluster
and (iv) any instruments' products on any cluster that can support it.
Approach:
Evaluate each of these approaches using (i) the results from dynamic studies using the
latest Release B baseline and (ii) availability, reliability and cost of different types
of processing/networking technology from different vendors in the Release B time frame.
Evaluation Method:
The approaches could different for different DAACs and their selections will be based on
the following criteria:(i) Processing throughput requirements, (ii) availability in the
Release B time frame, (iii) cost and (iv) technological risk.
Monthly Update:
N/A
Key Events:
A detailed description of the hardware configuration at various DAAC and the rational
leading to the decisions will ne given on the DAAS Specific Design section of the
Release B DID 305 to be published at CRD in April 1996.
Results:
February, 1996
Based on the results of other related studies the following decisions have been made for
Release B Data Processing hardware: A cluster will consist of either a SGI/PCA class
platform or a Sun Ultra 1 Model 140 and host attached disk (RAID) will be used. As a
result of these decisions a major instrument, such as MODIS, will use multiple clusters
while some less demanding instruments will share a cluster. The processing latency due
to network transfer will be mitigated using predictive staging.
Documents:
N/A
Key Risks:
N/A
Type: prototype | Status: Completed | Category: Engineering
Release: Release B | Sub-System: S-DPS | Organization: SCDO
Purpose: risk mitigation
Principle Investigator: Doug Sims | Lead: Doug Sims
Evaluation Lead: Ramsey Billups | ESDIS Lead: Steve Kempler
Start Date: 01-Oct-1995 | End Date: 31-Dec-1995 | Effort: 3 man months
Objective:
Determine if the COTS selection for Release A will actually scale up to Release B
performance requirements. Key issues are the ability to use the product to
monitor jobs and the ability of the product to handle job throughput (currently 5,000 PGE
activiations/day at GSFC).
Approach:
Once the COTS product is purchased and configuration for Release A has begun,
attempt to push to Release B levels where appropriate. This will involve development
of interfaces to support and simulate Release B processing loads.
Evaluation Method:
A program was written to create large (20,000 jobs) AutoSys job loads using a simple job
box model. Throughput was measured for various processing scenarios. AutoSys GUI
monitor performance was both subjectively evaluated and measured using Unix performance
monitoring tools.
Monthly Update:
Final - January 1996
It was decided after the vendor meeting to focus on AutoSys throughput issues.
A new test bed consisting of a more powerful "queuing server" machine and 8 clients was
requested. This protype has been closed out. A new prototype has been opened named,
"AutoSys Scalability".
December 1995
MRS assigned two of their people to work on the prototype. A meeting with the vendor is
scheduled for January to discuss our throughput concerns.
November 1995
Ran the 20,000 job prototype on a SPARCstation 20/71 and the AutoXpert GUIs aborted with
a memory error, even though the machine was configured with 384 MB. Working with the
vendor to determine the nature of the problem so that benchmarking can proceed. The
vendor has stated that the AutoXpert GUIs use 3-5 KB of memory per job per GUI.
October 1995
Determined that at least an HP 735/125 class machine with 128+ MB is required for the
20,000-job prototype. Submitted a request to the EDF CCB to identify a new platform for
testing. The full prototype status report is posted on the ccmail AutoSys bulletin board.
September 1995
Two SPARCstations 20/40 with 64 MB of memory have been allocated for PDPS prototyping.
AutoSys and AutoSys Xpert were installed and work commenced on 10/4.
August 1995
A request has been submitted to the EDF CCB to obtain computer resources for prototyping.
Procurement of resources should be complete by mid-September.
July 1995
COTS have been procured. Meetings have been held with various vendors. Outcome
will be integrated into the plan.
Key Events:
IDR
Results:
Final Results - January 1996
JobScape and TimeScape performance needs to be improved for large job loads.
The GUIs use over 5KB of memory per job definition. The vendor has promised a more
memory-efficient GUI for the next release of the product (AutoXpert 2.0 - 8/96).
Throughput needs to be evaluated more thoroughly before any conclusions can be made.
However, from a monitoring standpoint alone, it would be desirable to keep the AutoSys
database free of non-active jobs during the day's processing. This would have the
beneficial result of improving monitoring and probably throughput performance.
Documents:
Lessons Learned Paper.
Key Risks:
S-7: Production and Planning for Release B
U-4: Processing and Storage for Standard Products
Type: prototype | Status: rejected | Category: Engineering
Release: Release B | Sub-System: C-CSS | Organization: N/A
Purpose: risk mitigation
Principle Investigator: Shabahat Husain | Lead: Shabahat Husain
Evaluation Lead: N/A | ESDIS Lead: N/A
Start Date: N/A | End Date: N/A | Effort: 36 man months
Objective:
- Focuses on ODP trader with type management based on user-query.
- Core domain problem isolation (DIM/LIM, Advertising, Trader, ORB).
- Core functionality interface definition.
- Core functionality prototyping.
- Iterations as required
- Spiral to next ring (Document, Language, Data/File Server, GUI, Interoperability).
- Iterate and Spiral to third ring (Sys. Mgmt, Performance, Transport).
Approach:
N/A
Evaluation Method:
N/A
Monthly Update:
August 1995
Status changed to rejected.
July 1995
No good users have been found for this so far. Status is on hold, possibly will be
rejected.
Key Events:
Post IDR Prototype
Results:
N/A
Documents:
Findings Report
Key Risks:
N/A
Type: Prototype | Status: Completed | Category: Technology
Release: Release B | Sub-System: C-CSS | Organization: N/A
Purpose: Technology assessment
Principle Investigator: Shabahat Husain | Lead: Steve Burrows
Evaluation Lead: Shabahat Husain | ESDIS Lead: Hal Folts
Start Date: 31-Jul-1995 | End Date: 24-Nov-1995 | Effort: 6 man months
Objective:
The purpose of the transaction processing (TP) prototype is to build and evaluate
a transaction processing product for use in ECS Release B.
Approach:
1. Identify candidate COTS products and select candidate implementation(s) based
on the 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, 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 product should provide the critical features:
1. Data integrity of mission critical data in the event of system failures.
System failures would include communications link failures/errors/outages,
sending/receiving platform failures (e.g., disk errors) and database errors.
2. All components must succeed or fail as a unit; component roll-back when
failure occurs.
3. Simultaneous transactions do not interfere with each other.
4. Transactions once committed are permanent and unaffected by subsequent errors.
Monthly Update:
January 96:
The phase 1 portion of this Prototype has been completed. Please see
the Results and Document section for more detail.
October 95:
The transaction processing study (Phase 1) has been completed. A white paper
will be written to discuss two different TP implementations (Encina and Tuxedo) and
our recommendation. The recommended software (Encina) has arrived. Phase 2 of the
prototype will include installation, configuration and test results of the newly
arrived software.
September 95:
- Several machines have been identified and prepared for use in the prototype
- A design plan has been devised
- We are currently waiting for the requested software to be delivered
August 95:
- Candidate COTS products and implementations have been identified
- The impact on subsystems has been explored: CSS, MSS and DSS are the primary effected
subsystems
- A detailed design plan is currently in the making
Key Events:
N/A
Results:
A white paper has been written documenting the completion of Phase 1
of the prototype. Phase 2 of the prototype has been cancelled as per
the management decision.
Documents:
White Paper, CSS Subsystem Design Document
Key Risks:
N/A
Type: prototype | Status: Completed | Category: Engineering
Release: Release A, B | Sub-System: F-CMS | Organization: FOS
Purpose: risk mitigation
Principle Investigator: C.W. Murphy | Lead: C.W. Murphy
Evaluation Lead: Andy Miller | ESDIS Lead: Mike Rackley
Start Date: 01-Jan-1994 | End Date: 31-Dec-1995 | Effort: 42 man months
Objective:
The Command Management Subsystem (CMS) supports safe commanding of the EOS spacecraft
and their associated instruments. The CMS translates and validates events from the
detailed activity schedules into: spacecraft commands; spacecraft loads; instrument
commands; and instrument loads. Errors occurring during the translation or validation
process are resolved via operator dialogue or interaction with the P&S subsystem. The
CMS builds an integrated load for each EOS spacecraft, as well as a ground script for
use in real-time operations. These CMS builds would nominally occur 2-3 days prior to
the target day. The real-time Command Subsystem would then nominally perform the uplink
of the integrated load 1 day prior to the target day.
The CMS system for ECS must support Target Of Opportunities (TOOs) and late changes. This
encompasses making modifications to stored commands and loads that have been previously
uplinked to the spacecraft. The CMS will determine what impacts, if any, the new or
changed event has on the current load. Impacts would include command level constraint
checks and onboard storage constraints. The CMS will be able to rebuild the integrated
load in its entirety or a subset of the load to ensure the most efficient use of the
TDRSS contacts.
Approach:
In order to refine the CMS requirements and operational concept a phased approach to
the prototype development is planned. Initially, a study of existing command management
systems will be performed in order to explore and document lessons learned. The focus
of the study will be to improve understanding of : the command analyst's job; usability
of current CMS; and tools and graphics that would prove useful. The findings of this
study will be presented at a Prototyping Results Review as well as in the first draft
of the CMS prototype report.
In the second phase, a working prototype will be developed. The prototype will model
an approach to TOO support. The effort will focus on: identifying the most effective
and efficient means of performing load modifications; insuring robustness; and the CMS
interface with the planning and scheduling subsystem. This prototype will allow
refinement of the CMS specific performance requirements for responding to TOOs and late
changes. The results of this phase will be presented at a Prototyping Results Review
as well as in the second draft of the CMS prototype report.
Finally, in the third phase of the prototype effort, approaches to validation will be
explored. A predictive model will be implemented for performing verification of spacecraft
loads. This prototype is dependent on the Decision Support Subsystem (DSS) prototype
effort and will allow the ECS program to access the usefulness of expert systems in
the command management arena. The results of this phase will be presented at a
Prototyping Results Review as well as in the final CMS prototype report.
Several criteria will be examined as part of the evaluation of the CMS prototyping
effort. The final working prototype will be demonstrated and responses from the users
will be compiled. The derived results, which will be included in the final report,
will include hardware requirements and recommendations as well as COTS software
recommendations. Additionally, the feedback from the demonstration will be used to
modify the operational concept and detailed requirements for the CMS with regard to
its functionality and ease of use. In addition, the results from this prototype will
be documented in the ECS Segment/Element Requirements Specification and will be
presented at the design reviews (i.e., PDR, CDR).
Evaluation Method:
The results of the study phase will be documented in a report summarizing lessons
learned from evaluating other CMS systems. Final working prototype will be
demonstrated and responses from the users will be compiled. The derived results,
which will be included in the final report. The feedback from the demonstration will
be used to modify the operational concept and detailed requirements for the CMS with
regard to its functionality and ease of use.
Monthly Update:
October 1995
The CMS prototype has completed its tasks, which were reported at
the FOS Prototype Results Review (PRR) in August 1995. These tasks were performed as
part of the pre-Critical Design Review (CDR) efforts (note: the FOS CDR was presented in
October 1995).
September 1995
This FOS prototype activity was significantly reduced due to FOS Critical Design Review
preparations.
August 1995
Prepared for FOS Prototype Results Presentation (PRR) this month. Results of
analysis were presented at the FOS PRR on August 24, 1995 to the AM-1 project
and ESDIS. Reference the FOS PRR slides for further information.
July, 1995 - They are working on the generation of the absolute time command load.
Key Events:
Prototype Results Review - August 25, 1995
Results:
Evaluated and contracted different heritage CMS systems; developing CMS prototype
using object-oriented techniques.
This prototype has been completed as of October 1995.
Documents:
Command Management Prototype Study Phase Results for the ECS Project, dated June 1994
document # 194-813-SI4-005.
FOS Prototype Results Review (PDR), dated February 22, 1995
FOS Prototype Results Review (PRR), dated August 24, 1995
document #707-PT-005-001
Key Risks:
A-3
Type: study | Status: Completed | Category: Technology
Release: Release A, B | Sub-System: F-ANA | Organization: FOS
Purpose: technology assessment
Principle Investigator: Jon Kuntz | Lead: Jon Kuntz
Evaluation Lead: Andy Miller | ESDIS Lead: Mike Rackley
Start Date: 01-Jan-1994 | End Date: 31-Dec-1995 | Effort: 48 man months
Objective:
The goal of this study is to prototype and analyze the use of expert/rule-based system
technology as it applies to decision support roles in the area of operations. This
analysis is to be accomplished via prototyping of the Expert Advisor/Decision Support
System (DSS), which is an expert system tool, potentially used by the spacecraft
operations staff at the EOS Operations Center (EOC) to monitor, analyze, query, and
assess both the current status and the potential status of the spacecraft. The DSS's
capabilities include the detection and resolution of anomalies, assistance in
configuring the spacecraft resources, advising the operator of the consequences of
proposed actions, and general spacecraft information and status reporting.
Since the DSS is a potential tool available to the spacecraft analysts, it must be
developed to fit architecturally, as well as functionally, within the overall design
of the FOS. It must be easy to use, provide accurate, timely, and reliable data, and
support the needs of the Flight Operations Team (FOT). The primary objectives of this
prototype effort are to perform a technology assessment of the existing COTS expert
shell systems available, to evaluate existing operational expert systems such as the
NASA GenSAA system, and to prototype a rule-based DSS of a single subsystem of the
spacecraft. By targeting these objectives, upon the completion of the prototype the
FOS developers will be able to accurately assess the feasibility of incorporating an
expert system into the spacecraft control center which would provide valuable
information to the FOT. Additionally, a cost/benefit analysis will be performed to
determine the tradeoffs of functional capabilities to implementation costs.
Approach:
Initially, the work to be done during the study phase of this prototype involves the
evaluation of existing COTS expert system shells and their applicability to the FOS
needs. Also, the evaluation of expert systems currently being used in both control
center environments as well as other domains will be undertaken to determine the
strengths and weaknesses of each system. In parallel with this evaluation process
will be the definition of the prototype to be built. This definition involves the
identification of the subsystem portion of the model. The study phase will culminate
with a report which presents the findings of the evaluations.
The second phase of the prototyping efforts involves the actual development of the
working prototype. For control purposes, a single subsystem will be modeled during
this effort. Once the subsystem has been identified, a thorough investigation of all
available documentation as well as discussions with the appropriate personnel
will be undertaken to identify and quantify the requirements of the subsystem for model
development. The evaluation of existing operational expert systems will lend insight
into the needs and requirements of the users. Taking into account the requirements of
the system and the operational needs of the users from the lessons learned approach,
a rule-based model will then be developed for the subsystem. Performance measurements
will be taken, and the prototype demonstrated and critiqued by the ECS team, NASA, and
spacecraft analysts. In addition, analysis of the mechanism and complexity in getting
the expert information into the model will be performed. This analysis will be used to
perform a cost/benefit analysis of the extent to which an expert advisor can be
integrated into the FOS including its operational value versus its relative cost.
A report to be provided following the demonstration of the working prototype will contain
the results of the demonstrations, the feedback from the attendees, and the cost/benefit
analysis of the expert advisor.
The final phase of the prototyping effort is the generation of the final report. Several
criteria are examined as part of the DSS prototyping effort evaluation. The evaluation
process will include the compilation of responses from the reviewers of the demonstrations;
the assessment of ease of implementation by the development team; performance measurements;
and reports on applicability to flight operations procedures, portability, and growth
potential. The results included in the final report include hardware requirements, the
COTS tool recommendations, and the recommendation for the implementation approach for
inclusion of the DSS into the spacecraft control center. The results refine the
operations concept, are documented in the ECS Element/Segment Requirements Specification
are presented at the design reviews (i.e., PDR, CDR).
Evaluation Method:
Evaluate the compilation of responses from the reviewers of the demonstrations, the
assessment of ease of implementation by the development team, performance measurements,
and reports on applicability to control center procedures, portability, and growth
potential.
Monthly Update:
October 1995
The DSS prototype has completed its tasks,
the FOS Prototype Results Review (PRR) in August 1995. These tasks were performed as
part of the pre-Critical Design Review (CDR) efforts (note: the FOS CDR was presented in
October 1995).
September 1995
This FOS prototype activity was significantly reduced due to FOS Critical Design Review
preparations.
August 1995
Prepared for FOS Prototype Results Presentation (PRR) this month. Results of
analysis were presented at the FOS PRR on August 24, 1995 to the AM-1 project
and ESDIS. Reference the FOS PRR slides for further information.
July, 1995 - Results will be detailed at the August review meeting.
Key Events:
Prototype Results Review - August 25, 1995
Results:
Evaluation of COTS products described in prototype report.
This prototype has been completed as of October 1995.
Documents:
Decision Support System Prototype Results Prototype first draft for the ECS, dated
September 1994, document # 194-813-SI4-010.
FOS Prototype Results Review (PDR), dated February 22, 1995
FOS Prototype Results Review (CDR), dated August 24, 1995,
document #707-PT-005-001
Key Risks:
N/A
Type: prototype | Status: Completed | Category: Engineering
Release: Release A, B | Sub-System: F-FUI | Organization: FOS
Purpose: requirement clarification
Principle Investigator: Jim Creegan | Lead: Jim Creegan
Evaluation Lead: Andy Miller | ESDIS Lead: Bob Dutilly
Start Date: 01-Aug-1993 | End Date: 31-Dec-1995 | Effort: 48 man months
Objective:
Refine the operational concept and requirements associated with the IST.
Approach:
Review of Instrument Flight Operations Understanding (IFOU) documents and discussions
with each of the AM spacecraft instrument builders. In parallel, an effort to quantify
all functionality necessary for instrument control and monitor. Following the above
efforts, a first pass functional breakdown between the EOC, ICC, and ISTs will be
developed. Prototype will be created and demonstrated to the instrument developers and
NASA. Subsequent prototypes will be developed and refined by incorporating the feedback
from the reviewers.
Evaluation Method:
Evaluated from surveys completed by the user community after viewing and working with
the prototype. Criteria includes functional completeness, ease of use, clarity of data
presentation, and look and feel. Results will be compiled into a report and presented
to the instrument community for concurrence and comments.
Monthly Update:
October 1995
The IST prototype has completed its tasks, which were reported at
the FOS Prototype Results Review (PRR) in August 1995. These tasks were performed as
part of the pre-Critical Design Review (CDR) efforts (note: the FOS CDR was presented in
October 1995).
September 1995
This FOS prototype activity was significantly reduced due to FOS Critical Design Review
preparations.
August 1995
Prepared for FOS Prototype Results Presentation (PRR) this month. Results of
analysis were presented at the FOS PRR on August 24, 1995 to the AM-1 project
and ESDIS. Reference the FOS PRR slides for further information.
July, 1995 - Completed mock-up of Load Manager screens.
Continued integration of the help tool into the prototype, including conversion of the
MS-Word documents to HTML, accessing Netscape from the document and the inclusion of
hypertext keys.
Key Events:
Prototype Results Review - August 25, 1995
Reflected in the FOS Requirements Specification and will be presented at the design
reviews. Results have been folded into the next iteration of the IST prototype and,
along with subsequent IST prototypes, will be used to refine the IST operations concept
and its corresponding requirements, design, and implementation approach.
Results:
Instrument Support Toolkit Prototype Results Report for the ECS Project, dated February
1994, Document # 194-813-SI4-001. (Phase 1)
Instrument Support Toolkit Prototype
This prototype has been completed as of October 1995.
Documents:
Results Report for the ECS Project, dated August 1994. (Phase 2) Document #
194-813-SI4-001.
FOS Prototype Results Review (PDR), dated February 22, 1995
FOS Prototype Results Review (CDR), dated August 24, 1995,
document #707-PT-005-001
Key Risks:
N/A
Type: prototype | Status: Completed | Category: Engineering
Release: Release A, B | Sub-System: F-PAS | Organization: FOS
Purpose: requirement clarification
Principle Investigator: Bill Moore | Lead: Bill Moore
Evaluation Lead: Andy Miller | ESDIS Lead: Tom Barlett
Start Date: 01-Jan-1995 | End Date: 11-Aug-1995 | Effort: 52 man months
Objective:
To mitigate and resolve the following risks and uncertainties:
1. Operations concept details including EOC/ICC/IST interactions, global and local planning
concepts, and conflict resolution;
2. User interface requirements. In particular the definition of the problem space for
operator jobs and tasks so that the displays enhance operator problem solving capabilities
and productivity;
3. Constraint-free planning requirements. Identification and characterization of constraints
to meet the required accuracy and performance levels;
4. IST prototype support for tool set integration and software architecture issues to be
addressed under the IST prototyping effort.
Early prototype objectives include establishment of an evolvable development framework
that has a proven and validated baseline and mission management technology transfer from
MGPS and Hughes IR&D to the ECS P&S development team.
Approach:
Establish the basic planning system framework and evolve and refine system requirements
to the design of the prototype. Prototype will be based on the Hughes Mission Management
Class Libraries and ECS specialization's will be derived to meet the P&S requirements.
Prototype will be a modular object oriented design and will be built to operations quality
standards to facilitate evolution to fully operational software. Initial prototypes will
focus on higher level Operations concept issues and only implement simple constraint
models and scheduling algorithms.
Evaluation Method:
Includes user and customer feedback, engineering evaluation of critical performance and
design parameters. User and customer feedback will be solicited at formal demos and
informally surveying the prototype construct phase. Feedback and comments will be tracked
and displayed with the concurrence of the customer. Reports which compile and
summarize the results at each prototype phase will be issued to the customer and
interested users.
Monthly Update:
October 1995
Prototype Results Review report was released (813-RD-013-001) 31 October 1995.
This is the final report and completes the P&S prototyping effort.
The FOS prototypes have completed the majority of their tasks, which were reported at
the FOS Prototype Results Review (PRR) in August 1995. These tasks were performed as
part of the pre-Critical Design Review (CDR) efforts (note: the FOS CDR was presented in
October 1995). Any future prototype task plans will be reported and statused in the next
ECS Prototype Progress Report.
September 1995
This FOS prototype activity was significantly reduced due to FOS Critical
Design Review preparations.
August, 1995 - Successful Prototype Results Review on August 24, 1995. Results from
the Resource Model Distribution, Access, Activity Definition, and Activity Constraint
prototypes were presented. Reference the FOS PRR slides for further information.
July, 1995 - Results will be detailed at the August review meeting.
Key Events:
Prototype Results Review report - October 31, 1995
Prototype Results Review - August 25, 1995
document #707-PT-005-001
Results:
August, 1995 Several comments were received with regard to the differences between
activity definitions and resource state or mode. As a result we are investigating the
feasibility of displaying both on the timeline.
Prototyped P&S software including definition of P&S framework, received feed from users,
reflected user interfaces. Phase 3 report released March, 1995. Phase 4 report to be
released mid September, 1995.
Documents:
Planning and Scheduling Prototype Results Report dated October 31, document
# 194-813-RD-013-001.
Planning and Scheduling Prototype Results Report dated January 21, document
# 194-813-SI4-002 1994.
Planning and Scheduling Prototype Results Report for the ECS Project, Part B dated
August 1994 document # 194-813-SI4-006.
FOS Prototype Results Review (PDR), dated February 22, 1995
Key Risks:
N/A
Type: prototype | Status: Completed | Category: Engineering
Release: Release A, B | Sub-System: F-TLM | Organization: FOS
Purpose: risk mitigation
Principle Investigator: Debbie Dunn | Lead: Debbie Dunn
Evaluation Lead: Andy Miller | ESDIS Lead: Mike Rackley
Start Date: 01-Apr-1994 | End Date: 31-Dec-1995 | Effort: 12 man months
Objective:
To determine if any pertinent issues relating performing the decommutator process using
object-oriented techniques.
Approach:
Compare and contrast several approaches to object oriented design of the decommutator.
Evaluation Method:
Two separate approaches to an object oriented telemetry decommutation process were
prototyped by the real-time group. Two software engineers were assigned to each of the
prototyping efforts. Having two teams helped in several areas:
1. Allowed different models and decommutation philosophies to be tested (resolved
alternative design approaches).
2. Permitted performance comparisons between prototypes with and without a C++ class
library base.
3. Development could take place on different hardware platforms. The software would later
be ported and tested on the alternate machine. Hewlett-Packard and Digital Equipment
Corporation workstations and tools were used for development.
4. Gave the engineers more exposure to C++ programming.
The two decommutator prototypes were identified at Model-A and Model-T. In addition to the
decommutation prototypes, a small CCSDS packet driver was written in C++.
The functional goal of the prototypes was to decommutate simulated AM-1 housekeeping
telemetry. The telemetry would be in CCSDS packets, each packet containing an AM-1 major
cycle. One complete AM-1 master cycle requires sixty-four major cycles. The prototypes
were to:
- Extract discrete parameters
- Extract analog parameters
- Limit check the parameters
- EU convert the parameters (using third order polynomial equations)
- Extract packet time
- Check packet application identifier
- Extract and use packet sequence number to derive major cycle number and parameter map
Model-A
The philosophy for Model-A was to be extremely small, fast, and fairly application
specific. Flexibility was not a major design goal. Small C++ classes were developed and
no C++ class library was utilized. Model-A adhered to a strict use of pointers and some
minor use of static variables. The Model-A developers also created and used a flat file
data base.
Although the prototype is doing relatively simple documentation, data base initialization
and telemetry decommutation rates of the Model-A prototype suprised us. On the DEC Alpha,
the data base loaded in less than five seconds. The maximum telemetry decommutation rate
was approximately 3.1 Mbps.
Most Model-A development problems occurred in the area of I/O operations and manipulation.
One HP C++ compiler bug was uncovered (allowed a non-standard static variable
initialization that was later caught by the DEC compiler).
Model-T
The philosophy for Model-T was to provide a generic decommutation process. For this effort,
flexibility was a design driver. In addition the Model-T would employ the Hughes Class
Library (HCL) as its foundation, so again performance would be a critical issue. The
prototype developers were interested in finding out whether the class library would impose
significant overhead.
Because Model-A development was slightly ahead, the Model-T software engineers were
required to write a data base conversion routine. This was also accomplished using HCL.
The result is an object oriented data base that is read upon Model-T start-up. Reading
the data base and initializing the objects takes approximately one minute.
A maximum decommutation rate of roughly 2.9 Mbps proved that these is very little, if any,
penalty incurred when using a C++ class library wisely. Differing decommutation rates
between the Model-A and Model-T prototypes are more likely attributed to their distinct
designs.
Note: Please see Model-T specifics below.
Monthly Update:
October 1995
The Telemetry prototype has completed its tasks, which were reported at
the FOS Prototype Results Review (PRR) in August 1995. These tasks were performed as
part of the pre-Critical Design Review (CDR) efforts (note: the FOS CDR was presented in
October 1995).
September 1995
This FOS prototype activity was significantly reduced due to FOS Critical Design Review
preparations.
August 1995
Prepared for FOS Prototype Results Presentation (PRR) this month. Results of
analysis were presented at the FOS PRR on August 24, 1995 to the AM-1 project
and ESDIS.
July, 1995 - Results will be detailed at the August review meeting.
Key Events:
Prototype Results Review - August 1995
Results:
This prototype has been completed as of October 1995.
3/24/95
1. C++ class organization allows for localized code modifications. Member functions were
rewritten to increase execution speed with absolutely no affect on any other application
code. No "ripple" effect.
2. The class library provided a solid framework and little additional overhead. Much
low level functionality is inherited from the library (i.e., stream I/O operations).
The class library "building blocks" facilitate rapid development and enforce good
programming habits.
3. Minimize run time construction and deletion of objects. The prototypes have all object
creation occurring at program start-up.
4. Where efficiency is important, pass objects and arguments by reference or use pointers.
The prototypes adhere strictly to this concept. Avoid passing by value.
5. Override cumbersome or inefficient class library functions. C++ makes this simple.
General Observations from Model-T (telemetry processing prototype incorporating HCL):
- Speed was primary concern (because of C++ and HCL):
-- processing rate of 2.9 Mbps very acceptable
-- not as big a speed penalty from inheritance as expected (the code we wrote went
only 2 levels deep but some of the HCL objects we incorporated were as deep as 4 levels)
- Flexibility a secondary concern
-- classes allowed painless modifications
--- for example, we simplified the conversion algorithm for analog parameters
for a more fair comparison with Model-A
-- we also changed some object attributes from class types to pointers and made
necessary implementation changes without affecting the external use of the object
-- HCL provided solid "framework"
- General Rules
-- no run-time construction/deletion of objects
--- pass objects as references to/from operations
- Rapid development
-- HCL "building blocks" facilitated rapid prototyping
--- HString simplified cumbersome char* string manipulating
--- stream I/O operations allowed "object database"
--- command line made easy
--- lists, sets, arrays, etc. easy to use
Documents:
FOS Prototype Results Review (PDR), dated February 22, 1995
FOS Prototype Results Review (CDR), dated August 24, 1995
document # 707-PT-005-001
Key Risks:
E-4
Type: study | Status: in-progress | Category: Engineering
Release: Release A, B, C, D | Sub-System: N/A | Organization: SCDO
Purpose: risk mitigation
Principle Investigator: Brand Fortner | Lead: Brand Fortner
Evaluation Lead: N/A | ESDIS Lead: N/A
Start Date: 01-SEP-1994 | End Date: N/A | Effort: 20 man months
Objective:
To evaluate data formats currently in use in the earth science user community in order
to define scopes of consensus, and to arrive at a set of proposed ECS standards for
data storage, processing, and distribution.
Approach:
Investigate previous and in-process data file format standardization initiatives, in
order to obtain lessons learned. Define scopes of consensus in order that
standardization may be reached among a subset of users.
Evaluation Method:
Evaluates data formats currently in use in V0 and other operational systems in terms
of their usability, acceptance by the user community, ease of conversion between
formats, and compatibility with off the shelf and public domain visualization and
analysis packages.
Monthly Update:
February, 1996 - Grid, Point, and Swath design documents available. Grid, Point and
Swath APIs available. These APIs were reviewed at a Data Modelling Working Group meeting
on February 1996. The API and design documents will be finalized in March 1996.
January, 1996 - HDF-EOS Metadata design document and HDF-EOS Swath design document made
available to teams. Grid API nearing completion, work continues on HDF-EOS metadata tools.
December, 1995 - Completed first point prototype API library to selected users. Point and
grid documentation will be delivered by the end of the month. Prototype Grid API
will be delivered by end of month.
November, 1995 - Delivered metadata paper, new versions of swath library and
documentation, and EOSView. Work continues on grid and swath standards and prototype
libraries
August, 1995 - Delivered following documents : Swath Paper, HDF-EOS Library design
document, HDF-EOS delivery schedule. Delivered Prototype HDF-EOS Swath library code and
documentation. Delivered new version of EOSView. All are available on HDF-EOS web page.
July, 1995 - Under Review, received late update: Finishing July 1995 release of
standards document and prototype code.
Key Events:
Delivery of prototype API for TRMM and HDF-EOS Primer in January 1996
Delivery of full prototype API in March 1996
Delivery of operational API and Release A version of EOSView in June 1996
Results:
A final studies report will contain recommendations for the ECS standard set of data
file formats. Progress of this study will continually be fed into the development of
the PGS toolkits.
Documents:
The study group will deliver a proposed HDF-EOS standards document in July 1995,
December 1995 and May 1996 along with prototype code.
Key Risks:
U-2
Type: study | Status: completed | Category: Technology
Release: Release A | Release B | Sub-System: C-CSS | Organization: MRS
Purpose: risk mitigation
Principle Investigator: Peter Danzig (USC) | Lead: Mary Armstrong
Evaluation Lead: N/A | ESDIS Lead: N/A
Start Date: 01-Mar-1994 | End Date: 01-Oct-1994 | Effort: N/A man months
Objective:
1. Provide description of tools/techniques available for internet performance analysis.
2. Evaluation of TCP Vegas to determine its stability and bulk transport performance.
3. Prototype and RFC design of object cache. Xmosaic interface development to object
cache.
Approach:
See proposal by USC.
Evaluation Method:
See proposal by USC.
Monthly Update:
July 1995
Study has been completed and document have been written.
Key Events:
N/A
Results:
July 1995
Study completed: see papers on TCP Vegas evaluation and object cache.
12/23/94
Final Report is still pending
Documents:
"Evaluation of TCP Vegas: Emulation and Experiment" by Jong Suk Ahn, Peter B. Danzig, Zhen
Liu, and Limin Yan;
http://excalibur.usc.edu/research/vegas/doc/vegas.html
"A Hierarchical Internet Object Cache" by Danzig et. al;
Key Risks:
N/A
Type: prototype | Status: rejected | Category: engineering
Release: Release B | Release C | Sub-System: N/A | Organization: N/A
Purpose: functional enhancement
Principle Investigator: Ellen Chilikas | Lead: Unassigned
Evaluation Lead: Unassigned | ESDIS Lead: Unassigned
Start Date: N/A | End Date: N/A | Effort: 0 man months
Objective:
Create low-end GUI capability
Approach:
N/A
Evaluation Method:
N/A
Monthly Update:
July 1995 - At the time of this report, this has been listed as rejected and no
requirements for ECS. This could be re-activated if approved.
Key Events:
N/A
Results:
No results.
Documents:
N/A
Key Risks:
N/A
Type: prototype | Status: rejected | Category: technology
Release: Release B | Release C | Sub-System: N/A | Organization: N/A
Purpose: functional enhancement
Principle Investigator: Unassigned | Lead: Unassigned
Evaluation Lead: Unassigned | ESDIS Lead: Unassigned
Start Date: N/A | End Date: N/A | Effort: 0 man months
Objective:
ASTER U.S. Team sees the need for a tool that mosaics ASTER images together or a part
of the product generation process that mosaics ASTER images. ASTER data will be like
Landsat TM data in that it will probably be collected as scenes, given the thinking
of many ASTER U.S. Science Team Members. If a study straddles two scenes, then
mosaicing of the data sets is needed. Current IMS specs do not call for such a tool
in the IMS tool kits ( the data visualization part of the tool kit) or as a function
supported by the other IMS tools. Hence it appears that unless an investigator includes
software for mosaicing in his/her standard product generation software, mosaicking will
have to be done by an investigator at his/her SCF. This will impede some investigator
s from doing science.
Approach:
Possible solutions:
1) The IMS tool kit will probably be robust enough that mosaicing of images would be
included as a function (almost all commercial COTS visualization software have this
as a function, as well as many public domain packages.)
2) The spec provides for subsetting capabilities of data, and could be modified to
include mosaicing as part of the subsetting option
Evaluation Method:
Plan not developed yet;
Monthly Update:
July 1995 - As of this time, this has been reported as rejected due to no
need/requirements. This could be reactivated if so deemed.
Key Events:
N/A
Results:
Not implemented.
Documents:
N/A
Key Risks:
N/A
Type: prototype | Status: rejected | Category: engineering
Release: Release B | Release C | Sub-System: N/A | Organization: N/A
Purpose: functional enhancement
Principle Investigator: Ellen Chilikas | Lead: Unassigned
Evaluation Lead: Unassigned | ESDIS Lead: Unassigned
Start Date: N/A | End Date: N/A | Effort: 0 man months
Objective:
Create a Quicklook capability to provide near real time data to users.
Approach:
N/A
Evaluation Method:
N/A
Monthly Update:
July 1995 - As of this report, this has been listed as rejected due to no requirements;
This could be reactivated if approved by the evaluation committee.
Key Events:
N/A
Results:
No results.
Documents:
N/A
Key Risks:
N/A
Type: Study | Status: In-Progress | Category: Engineering
Release: Release B | Sub-System: S-DSS | Organization: SCDO
Purpose: Requirements Clarification
Principle Investigator: Carolyn M. Keydash | Lead: Michael Burnett
Evaluation Lead: Judy Smith, Michael Burnett | ESDIS Lead: Ben Kobler
Start Date: October 1995 | End Date: April 1996 | Effort: 6 man months
Objective:
The objective of this study is to determine the feasibility of providing inventory level
information to the user for data which has not yet been acquired or produced.
(See DID211 for Trade Study synopsis).
Approach:
The Analysis Plan in DID211 presents a set of questions which should be answered prior
to selecting an implementation alternative. In addition to answering those questions,
it will be necessary to evaluate the impact on processing demands, scheduling, storage
requirements, query response, product assessment performance, and the level of accuracy
and detail of information available to describe ECS holdings.
Input during the DMWG 5/95 from ASF, and ASTER will be strongly considered in the
recommendation.
Evaluation Method:
By Tuesday March 12th, the annotated outline will be delievered to Mike Burnett, and
Judy Smith for review. By Thursday March 14th, the draft version of the paper will be sent to Mike Burnett and Judy Smith for review and comment. The analysis will include a
recommendation.
Monthly Update:
March, 1996 Provide review team with a copy of the draft including recommendations.
February, 1996 The effect of five virtual metadata strategies (for creating metadata, and storing) identified by DID 211 for "on-demand" processing
at the EDC and the ASF DAACs have investigated. Impact of virtual metadata on level 3 and 4 requirements have been analyzed.
November, 1995 Identified sources, documents, milestones, selected proposed strategy
October, 1995 Outline under internal review.
Key Events:
2/96 A draft of the report "Virtual Metadata" has been developed and undergoing
internal review.
Results:
N/A
Documents:
1. DID211 Trade Summaries March, 1995 211-CD-001-002
2. DID304 Level 4 SPDS Requirements Specification for the ECS Project March, 1995
304-CD-002-002
3. DID216 Level 3 Functional and Performance Requirements for the ESDIS Core System
June, 1994 423-41-02
4. DMWG Workshop May, 1995 Workshop Presentation and Minutes
5. Process Vs Store Assessment Technical Paper July, 1995 221-TP-001-002
Key Risks:
N/A
Type: Prototype | Status: In-Progress | Category: Advanced
Release: Release B | Sub-System: C-CSS | Organization: Academic
Purpose: Risk Mitigation
Principle Investigator: William Emory (U. of Col.) | Lead: N/A
Evaluation Lead: Dmitri Schoeman | ESDIS Lead: Folts
Start Date: Sept 95 | End Date: Sept 96 | Effort: N/A man months
Objective:
In order to help reduce costly retransmissions of partially transferred files via ftp, we
are undertaking a prototype that will provide a checkpointed ftp transfer. This
checkpointing protocol will be developed and an rfc will be published to insure we get
potential user community feedback and a wide acceptance of the checkpointing feature.
The checkpointing will allow auto - restart of an interrupted transmission - the transmission
under ftp would restart from the stop of the last checkpoint instead of at the beginning
of the file.
This checkpointing ftp would first establish if both the receiving and transmitting sides
were running the checkpointing software; if so the checkpointing would be used. If not
a standard ftp transfer would take place.
Analysis will also be done to evaluate the incorporation of Kerberized ftp and the
checkpointing feature together.
Approach:
The University of Colorado (Dr. William Emery) is leading this effort and his group will
be producing the software and producing the rfc. While this is a prototype the code
will be robust so that it could be incorporated into the ECS. This should be available
for use in Release B. This software must be portable to many UNIX platforms.
In researching this project an existing software has been found that will provide the
basis for the checkpointed ftp transfer. This will allow the complete package to include
both client and server to have file recovery built in and to provided a graphical user
interface. Given the discovery of Ncftp (written by Mike Gleason, NCEMRSoft), the project
has been redefined to provide a COMPLETE package including both 'client' and 'server'
applications to perform the following operations: FTP with checkpointing (file recovery
built in), a friendly graphical interface capable of running on any tty screen (not necc.
to be on a graphics workstation to use), Kerberos (or possibly instead of kerberos, pgp
will also perform the authentication of kerberos as well, compress a file), and on the
fly compression (tar, compress and GNU zip, possibly pgp?). This package will be designed,
implemented and tested on UNIX systems including OSF/1, SunOS, Ultrix and AIX. In
addition to the development of this package, useful installation and help files will also
be created.
Evaluation Method:
ECS users and tirekickers would evaluate this software. From their feedback and testing
results that ECS and Emery will perform, we will decide on the migration into ECS code.
Monthly Update:
February 1996
The development and test environment has been installed during this period.
The Ncftp software package has been installed and tested during this period.
A draft of the changes to be made to this package; additional features being
added (including Kerberos security); and a revised implementation plan are being
prepared. A technical discussion and review session for this activity is being scheduled
to coincide with Dr. Emery's participation in the Rel B CDR.
January 1996
Work has uncovered software that will provide the initial basis for the
checkpointing feature to be added. Please refer to the update provided in the
Approach box above.
Preparations have also been made that provide the basis of understanding
that is needed to proceed to the coding phase of this project. This coding
phase is to start by the middle of February 1996.
October 1995
Work is progressing on the rfc for the checkpoint feature. Equipment is
being procured for the development.
Key Events:
publish rfc
update rfc with comments from user community
prototype code running
migrate code for Rel B use
Results:
February 1996
The Ncftp program has been installed and tested to document functionality and operation.
This baseline is to be used for design of the planned enhancements to this software.
January 1996
Given the discovery of Ncftp (written by Mike Gleason, NCEMRSoft), the project has been
redefined to provide a COMPLETE package including bothe 'client' and 'server'
applications to perform the following operations: FTP with checkpointing (file recovery
built in), a friendly graphical interface capable of running on any tty screen (not necc.
to be on a graphics workstation to use), Kerberos (or possibly instead of kerberos, pgp
will also perform the authentication of kerberos as well, compress a file), and on the fly
compression (tar, compress and GNU zip, possibly pgp?). This package will be designed,
implemented and tested on UNIX systems including OSF/1, SunOS, Ultrix and AIX. In
addition to the development of this package, useful installation and help files will also
be created.
Documents:
N/A
Key Risks:
N/A
Type: Study | Status: In Progress | Category: Technology
Release: Release A, B | Sub-System: C-MSS | Organization: Academic
Purpose: Technology Assessment
Principle Investigator: Paul Cohen (Univ. of Massachusetts) | Lead: N/A
Evaluation Lead: Jim Dennison | ESDIS Lead: N/A
Start Date: September 1, 1995 | End Date: August 31, 1996 | Effort: N/A man months
Objective:
The objective of this study is to identify and evaluate technologies that use artificial
intelligence (AI) methods to identify network conditions of interest to the MSS network
management function. The Technology will be able to identify permanent or transient
network faults and it will be able to detect conditions that can lead to faults. In
addition, it will be able to pick out the initial instigating fault from a flood of faults.
The most promising technology will be prototyped and tested with the intent of including
it in MSS's fault management software if it meets requirements.
Approach:
A literature search will be performed to identify promising technologies. The technologies
will be evaluated for their application to meeting the specified objectives. From the
evaluation, a technology will be selected that best satisfies the objectives. A software
prototype will be developed and tested against simulated ECS network conditions. The
result of the simulation will be analyzed. The prototype's performance will determine if
it should be included in MSS.
Evaluation Method:
A prototype of the selected technology will be executed against simulated ECS network
fault conditions. Its ability to detect and identify network faults before and after
errors occur will be measured.
Monthly Update:
February, 1996 - The Design and Requirements Specification Document for the deliverable prototype has been received and is currently under review.
A meeting has been planned for March 20 with UMass to discuss and finalize the requirements and design.
January, 1996 - As of the end of January 1996 a formal contract has not been signed.
However all issues have been worked out and it is anticipated that the contract will be
signed in early February, 1996. By verbal agreement a draft of the first deliverable
report titled "Technologies for Fault Management" has been received for review. The
second deliverable of the requirements specification and design specification for the
prototype will be recieved in February, 1996.
November, 1995 - The study was approved. Investigators from the University of
Massachusetts met with MSS personnel on November 16, 1995 in Landover, MD. to gain an
understanding of ECS's network configuration/environment and the tools available to
manage it. They were given a demo of HP Openview and Tivoli and an overview of ECS.
Currently a literature search and an analysis of the MSS network management task is being
performed and is to be completed by the end of November.
October, 1995 - This study is still being negotiated with the University of Massachusetts.
Key Events:
Contract issues were resolved.
A draft of the deliverable, "Technologies for Fault Management" was recieved.
Results:
January, 1996 - The first deliverable, a study of fault management technologies has been
recieved and is being reviewed by ECS.
November, 1995 - University of Massachusetts investigators have acquired the necessary
knowledge of ECS to perform literature search and task analysis.
Documents:
N/A
Key Risks:
N/A
Type: prototype | Status: in-progress | Category: Advanced
Release: Release C | Sub-System: N/A | Organization: SO
Purpose: risk mitigation
Principle Investigator: Tim Gubbels | Lead: Tim Gubbels
Evaluation Lead: Tom Dopplick | ESDIS Lead: Karen Moe
Start Date: 01-Sept-1995 | End Date: N/A | Effort: 48 man months
Objective:
Explore future SCF-DAAC and SCF-SCF interactions within EOSDIS by pursuing an end-to-end
science investigation.
1) Obtain Measurements to reduce uncertainty of end-to-end system performance
requirements
2) Involve SCFs in EOSDIS prototyping activities
3) Gain early experience with product integration and maintenance of remote SCF
environments (prototype SCF support)
4) Facilitate the SCF-SCF interactions and thereby enhance SCF-DAAC and DAAC-DAAC
interactions
Groundrules:
1) Prototype priorities should be risk driven (activities and order of implementation
chosen to maximize mission success)
2) Prototype must support science investigation(s) to attain meaningful evaluation
3) Prototype should be a long, stable effort (testbed)
4) Prototype should be build up incrementally with the goal of continually improved
service to users who agree to participate
5) Prototype should incorporate results of other technology assessment prototypes
as they are selected to be part of EOSDIS, and as needed to support prototype user's
needs
6) Interfaces should be well defined and consistent with ECS development to allow
for the integration of future EPs and high end prototypes
Approach:
Develop RFP, receive and revise SOW's
1) Evaluate current SCF environments to select common applications base for extending
interactions (NIIT/EDS ...) -- April-June 94
2) Replace existing Infrastructure with ECS communications services using the
evaluation packages -- Mid 94
3) Expand infrastructure investigations to include client-end services evaluation
- Tools late 94, ORBs early 95
4) Expand to include client-server interaction (small-scale archive interactions
with the goal of evaluating information management capabilities) -- Early 95
5) Expand server side investigations and relocate to one or more DAACs and/or
ADCs/ODCs to encompass distributed information management -- Mid 95
Evaluation Method:
The evaluation method is best described as an ongoing, dynamic peer review by
ECS Senior scientists and managers. Since this prototype is considered "ADVANCED",
much of the work is conceptual, and more amenable to scientific, rather than engineering,
review methods. At this early stage, no major reviews have been performed
Monthly Update:
October, 1995 - Work has officially begun at OSU, UNH, and HRL. Site "kickoff" visits
will be scheduled for December or January.
August, 1995 - Contract negotiations continued. Work expected to begin
in September.
July, 1995 - Contracts in review
February, 1996 - Prototype tracking broken up by university and this database entry closed.
See the individual entries for UNH and OSU to monitor progress. Rescope of each project
has recently occured over the November-February time period.
Key Events:
N/A
Results:
October, 1995 - Work has officially begun at OSU, UNH, and HRL. Site "kickoff" visits
will be scheduled for December or January.
12/23/94
HP computers have been delivered to OSU and UNH and will become part of the epcell
after DCE, OODCE, and EP4 are installed. The ATM link between UNH and OSU is
operational.
Documents:
N/A
Key Risks:
U-1, U-2, T-1, T-6, P-2
Type: Prototype | Status: In-Progress | Category: Advanced
Release: Release C | Sub-System: N/A | Organization: SO
Purpose: Risk Mitigation
Principle Investigator: Timothy Gubbels | Lead: Timothy Gubbels
Evaluation Lead: Tom Dopplick | ESDIS Lead: Karen Moe
Start Date: Oct. 1, 1995 | End Date: N/A | Effort: 12 man months
Objective:
Investigate the integration of external RDB into EOSDIS. Develop a variety of
alternative clients based on widely used COTS packages (Microsoft Access, Visual
Basic/Excel, Statistica, as well as Java/Newly developed class libraries. Examine
service empowerment and usage scenarios.
Approach:
Perform full SCF process/architecture characterization. Examine functionality and user
interactions/workflow processes within WWW- and COTS-based systems. Develop a prototype
WWW-accessible system and examine service empowerment and user interactions.
Evaluation Method:
Informal peer review by ECS scientists and engineers. Assessment of feedback provided by
user statistics on the WWW home page and community demos.
Monthly Update:
Key Events:
N/A
Results:
N/A
Documents:
N/A
Key Risks:
N/A
Type: Prototype | Status: In-Progress | Category: Advanced
Release: Release C | Sub-System: N/A | Organization: SO
Purpose: Risk Mitigation
Principle Investigator: Timothy Gubbels | Lead: Timothy Gubbels
Evaluation Lead: N/A | ESDIS Lead: N/A
Start Date: Nov. 1 1995 | End Date: N/A | Effort: 6 man months
Objective:
Perform initial research into requirements and perform top level design of a Dataset
Independent Subsetting Client (DISC) and a Dataset Independent Subsetting Server (DISS).
Investigate HDF-EOS granule "usability" in subsetting operations (evaluate metadata,
evaluate read API's). Evaluate write API's by producing test data.
Approach:
Research and document requirements based on all available sources of information. Perform
top-level design of client/server system using a OO methodologies. Attempt to "pull
apart" HDF-EOS files" , attempt to "manufacture" HDF-EOS files, attempt to extract
metadata from HDF-EOS files.
Evaluation Method:
Semiformal peer review by ECS scientists and engineers at regularly scheduled,
independent design reviews. Wide internal review of documentation deliverables.
Monthly Update:
Key Events:
N/A
Results:
N/A
Documents:
N/A
Key Risks:
N/A
Type: Prototype | Status: In-Progress | Category: Advanced
Release: Release C | Sub-System: N/A | Organization: SO
Purpose: Risk Mitigation
Principle Investigator: Timothy Gubbels | Lead: Timothy Gubbels
Evaluation Lead: N/A | ESDIS Lead: N/A
Start Date: Oct. 1, 1995 | End Date: N/A | Effort: 12 man months
Objective:
Investigate how Digital Libraries of the future will interact with ECS as Value Added
Providers (VAP's). Examine interoperability, alternate client paradigms, and potential
user interactions.
Approach:
Perform full Digital Library process/architecture characterization. Build sophisticated
WWW-accessible Java interface to the libraries collections and examine service
empowerment and invocation. Collaborate with the larger Digital Library community on the
full spectrum of interoperability issues.
Evaluation Method:
Informal peer review by ECS scientists and engineers. Assessment of feedback provided by
user statistics on the WWW home page and community demos.
Monthly Update:
Key Events:
N/A
Results:
N/A
Documents:
N/A
Key Risks:
N/A
Type: Prototype | Status: In-Progress | Category: Advanced
Release: Release C | Sub-System: N/A | Organization: SO
Purpose: Risk Mitigation
Principle Investigator: Timothy Gubbels | Lead: Timothy Gubbels
Evaluation Lead: Tom Dopplick | ESDIS Lead: Karen Moe
Start Date: Dec 1, 1995 | End Date: N/A | Effort: 12 man months
Objective:
Investigate the integration of GIS data and services into EOSDIS. Investigate hybrid
EOSDIS/GIS client metaphor for use in integrated coincident/geographic queries. Examine
interoperability issues as they relate to GIS SCF's.
Approach:
Perform full SCF process/architecture characterization. Examine functionality and user
interactions/workflow processes within WWW- and GIS-based Landsat Pathfinder IMS. Develop
a prototype WWW-accessible GIS/Query system and examine service empowerment and user
interactions.
Evaluation Method:
Informal peer review by ECS scientists and engineers. Assessment of feedback provided by
user statistics on the WWW home page.
Monthly Update:
Key Events:
N/A
Results:
N/A
Documents:
N/A
Key Risks:
N/A
Type: prototype | Status: proposed | Category: engineering
Release: Release A | Sub-System: N/A | Organization: N/A
Purpose: functional enhancement
Principle Investigator: Marilyn Kaminski | Lead: N/A
Evaluation Lead: N/A | ESDIS Lead: N/A
Start Date: N/A | End Date: N/A | Effort: N/A man months
Objective:
Investigate the use of AI/neural nets for QA (follow on studies for Jim Maslanik's
feasibility study); for discriminating erroneous data from real anomalies in station
data; or detection and connection of leads, optimal classification of sea ice, and
cloud discrimination. Richard Armstrong's work on interpreting passive microwave data
for snow cover over land taking into account terrain roughness, vegetation, wind,
slope, etc. was deemed to be a rule based system rather than AI. However, it was
potentially an important prototype issue for another reason. His algorithms require
data from a diversity of sources. Thus the issue of spotty access comes up. What if
one particular source isn't available at a given time? Should the algorithm default
to climatology? What are the impact of a distributed system on an algorithm that
requires data from many sources? Sd the required data be stored locally, or delivered
on a "just-in-time" basis?
Approach:
N/A
Evaluation Method:
N/A
Monthly Update:
July, 1995 - Under review. May move to Release C.
Key Events:
N/A
Results:
N/A
Documents:
N/A
Key Risks:
N/A