# Presentation: 475466

## Operations Concept Discussion 

-  - What do we need to get the ST tasks done

## Splinter Group Ground Rules 

- We are not developing the Ops Con
- This will be done by the Project Support Group
- The Ops Con will likely consist of
- Processes, assumptions, requirements, scenarios
- However, we recognize that the Ops Con must not overbuilt with such high expectations that it won’t work!
- We should
- Identify issues that need to be addressed
- Identify the infrastructure and processes that will be needed for the team to do its job
- Develop recommendations for the Ops Con

## Topics Discussed 

- How does the ST obtain the information it needs?
**How does the ST get its algorithm ideas and suggestions back into the system?**
- What’s the procedure for the team to interact with contractor concerning algorithm verification, product validation, and QA
- What does ST do if the EDR’s are not adequate as CDR’s?
- How does the ST make sure that it has necessary data flows and data system functionality (for EDR evaluations, for CDR generation and for feedback)?
- Point of Contact needed at the PSG for ST ITAR issues.
- How does the ST get its input into the NPOESS development?

## Topics Discussed 

- How does the ST obtain the information it needs?
- Instrument Performance
- Metadata, formats, file structures, algorithm status and performance (latest versions)
- QA plans, Test, Verification and Validation Data

## How does the ST get its algorithm ideas and suggestions back into the system? 
What is the procedure for interacting with the contractor?   Recognizing the interface to the IPO and Contractor is the PSG.
Can the ST obtain a list of names of Contractor POC’s for each EDR?
Can the PSG obtain a list of current issues that NGST is working on and their major concerns?
Can some face-to-face meetings (Dec-March 04) be organized for those algorithms where problems have already been identified or where there is insufficient data for the ST to proceed?
Special Recommendation - process needs to be set up for the first 1-9 months post first-light to allow ST feedback on product evaluation (will need timely info on calibration changes)
Examine possible interaction with IT Development (Raytheon Aurora-Factory)  

**What is the procedure for interacting with the contractor?**   Recognizing the interface to the IPO and Contractor is the PSG.
- Can the ST obtain a list of names of Contractor POC’s for each EDR?
- Can the PSG obtain a list of current issues that NGST is working on and their major concerns?
- Can some face-to-face meetings (Dec-March 04) be organized for those algorithms where problems have already been identified or where there is insufficient data for the ST to proceed?
**Special Recommendation** - process needs to be set up for the first 1-9 months post first-light to allow ST feedback on product evaluation (will need timely info on calibration changes)
- Examine possible interaction with IT Development (Raytheon Aurora-Factory)

**Topics Discussed**

## How does the ST get its algorithm ideas and suggestions back into the system? (cont’d)
To help the EDR meet Spec 
Need to help define/refine the specs in terms of validation data, sampling and stratification issues (conditions).
What is the Role of ST in evaluating whether product meets spec?
To help the EDR become a CDR
Concerns about need for reprocessing based on better understanding of instrument or degradation  
ST must identify the current gaps between CDR needs and the at-spec EDR’s
An indication of how this will be impacted by instrument performance 
Need a time schedule a) to Aug 04, b) pre launch 

- To help the EDR meet Spec
- Need to help define/refine the specs in terms of validation data, sampling and stratification issues (conditions).
- What is the Role of ST in evaluating whether product meets spec?
- To help the EDR become a CDR
- Concerns about need for reprocessing based on better understanding of instrument or degradation
- ST must identify the current gaps between CDR needs and the at-spec EDR’s
- An indication of how this will be impacted by instrument performance
- Need a time schedule a) to Aug 04, b) pre launch

## What’s the procedure for the team to interact with contractor concerning algorithm verification, product validation, and QA?
How does the ST make input to the emerging Cal/Val  and Product Acceptance Plans?
Recommend that the ST play an active role in developing the acceptance plan (workshop).
ST recommendations for validation data needs and collection should be incorporated.  
Need for additional Calibration and Orbital Maneuvers
What is the process for ST interaction with the Contractor QA process?
Off-line Cal/Val?

- How does the ST make input to the emerging Cal/Val  and Product Acceptance Plans?
- Recommend that the ST play an active role in developing the acceptance plan (workshop).
- ST recommendations for validation data needs and collection should be incorporated.
- Need for additional Calibration and Orbital Maneuvers
- What is the process for ST interaction with the Contractor QA process?
- Off-line Cal/Val?

## What do we do if the EDR’s are not adequate as CDR’s
How do we proceed in making the case for CDR development  (NASA/NOAA/CCSP)?
need an open dialogue 
What’s the process to define the CDR’s? 

- How do we proceed in making the case for CDR development  (NASA/NOAA/CCSP)?
- need an open dialogue
- What’s the process to define the CDR’s?

## How does the ST make sure that it has the necessary data flows and data system functionality (for the EDR evaluations, for the CDR generation, and for feedbacks)?
A workshop on data flows and planned system functionality is needed
Will the operational product software and test data sets be available?
The metadata should be sufficient to determine the inputs to a product (input pointers)?
A lessons-learned white paper on metadata and structure should be generated by the PSG with input from the ST 
Need to secure a Direct Feed from the IDPS to SDS 
(which products are created internally and which products are coming out (Appendix D) of the IDPS?) 
Will the ST have access to raw data and software?
We need a formal interface document IDPS and SDS? 

- A workshop on data flows and planned system functionality is needed
- Will the operational product software and test data sets be available?
- The metadata should be sufficient to determine the inputs to a product (input pointers)?
- A lessons-learned white paper on metadata and structure should be generated by the PSG with input from the ST
- Need to secure a Direct Feed from the IDPS to SDS
- (which products are created internally and which products are coming out (Appendix D) of the IDPS?)
- Will the ST have access to raw data and software?
- We need a formal interface document IDPS and SDS?

## How does the ST make sure that it has the necessary data flows and data system functionality? 
What procedure will the ST have for accessing data in the ADS (SDRs, RDR’s, EDR’s, Intermediate products, near real time data, archived data)
Special consideration will be needed for automated data feeds rather than standard customer, Do we need to develop a formal interface document?   
NPP1 (EDR testing and evaluation) 
SDS/CARS – Converting L2 EDR’s into CDR’s, from scratch CDR production (including intermediate products), product distribution, archive,
Need to consider product dependencies  
Reprocessing required for CDR’s 
What software and data formats will be made available for product checkout?
Need to undertake planning on the interfaces between the operational system  and the science team 
Time schedule

- What procedure will the ST have for accessing data in the ADS (SDRs, RDR’s, EDR’s, Intermediate products, near real time data, archived data)
- Special consideration will be needed for automated data feeds rather than standard customer, Do we need to develop a formal interface document?
- NPP1 (EDR testing and evaluation)
- SDS/CARS – Converting L2 EDR’s into CDR’s, from scratch CDR production (including intermediate products), product distribution, archive,
- Need to consider product dependencies
- _Reprocessing_ required for CDR’s
- What software and data formats will be made available for product checkout?
- Need to undertake planning on the interfaces between the operational system  and the science team
- Time schedule

##  
How does the ST get its input into the NPOESS development    

- How does the ST get its input into the NPOESS development

## Recommendations 

- Need a better understanding of the lines of communication
- Need information from NASA management on plans for SDS/CARS development ASAP
- Suggest early implementation and testing of data flows and interfaces – this will be critical for the CDR’s
- We need to identify high risk areas and topics requiring discussion meetings between ST and contractors to help share lessons learned more formally e.g.
- Metadata, File Conventions
- Algorithm verification and validation data needs
- Product acceptance planning
- IDPS, ADS data access and functionality

## Recommendations 

- Management needs to merge the various science advisory processes (ST, OATS, IPT’s) as far as possible to avoid conflicting advice
- Minutes of or attendance at meetings
- A List of Contractor POC’s for each algorithm would be useful
- The ST needs to play an active role product acceptance planning – providing an opportunity for interaction on product validation
- Special process needs to be set up for the first 1-9 months post first light to allow the ST input on product eval’n and feedback – also need up to date info needed on calibration changes