# Presentation: 266177

## Irene Bibyk
Tim Rykowski
Bob Schweiss

June 28, 2001

**Mission/Science Operations**

**Irene Bibyk**
**Tim Rykowski**
**Bob Schweiss**
**June 28, 2001**

## Mission/Science OperationsTopics

**Recommended Implementation Approach**
**Recommended Operations Staffing Approach**
**Critical Requirements and Assumptions**
**Cost Summary**
**Options Presented**
**Basis of Estimate**
**Additional Trades to Consider**
**Risk Assessment**
**Issues and Concerns**
**Back-up Slides**

## Mission/Science OperationsRecommended Development Approach

**Use Berkeley SSL MOC as basis for SNAP MOC development**
- Will meet all operational requirements for SNAP operations
- Proven system operationally (FAST support, will support HESSI)
- Includes basic functionality, plus automation tools to support SNAP operations in an 8x5 manner
**Use NERSC at Berkeley for L0 and higher level data processing**
- Significant storage and computing resources currently available
- Potential modifications to this system were not considered as part of this study and may need to be investigated
**Minimal modifications will be required to Berkeley SSL MOC to support SNAP operations**
- Some hardware upgrades are necessary (additional dedicated string for SNAP R/T support, additional general purpose workstations, network hardware)
- SNAP software-specific modifications, primarily to support
- Flight dynamics operations (I.e., lunar flyby) during commissioning
- Command management
- Mission/Science planning and scheduling

## Mission/Science Operations Recommended Operations Staffing Approach

**Recommend 8x5 (weekday, prime shift) staffing profile for routine mission operations**
**Most cost-effective solution for SNAP Mission Operations**
**Appropriate for both 3 and 5 ground station option**
**Scheduling complexity not much different between two options**
**Relatively simple mission operations concept allows 8x5 operations approach to be pursued:**
**Minimal instrument planning and scheduling (target observations uplinked once every 4 days)**
**No orbit maneuvers beyond commissioning phase**
**Minimal recovery operations conducted for data lost or not available**
**Spectroscopy and spacecraft housekeeping data stored on-board, replay from storage can be automated and accommodated in nominal 55 Mbps downlink**
**No attempts to store/recover other data lost due to link problems, gaps in station coverage**

## Mission/Science OperationsCritical Requirements and Assumptions

**Data rates:**
- Average SNAP instrument data rate: ~52 Mbps
- Includes lossless compression plus CCSDS overhead
- Average SNAP HK data rate: 16 kbps
**Data Latency:**
- ~4 days latency to deliver raw instrument data to NERSC is acceptable.
**Space-Ground contact profile**
- One 8 hour contact per day at each of three sites (Berkeley, France, Japan)
- Some gaps in coverage expected, gaps would be reduced by optional use of Hawaii, Santiago stations
**MOC functionality:**
- MOC provides “standard” set of functionality to support Mission Operations (e.g., S/C and instrument commanding,mission planning/scheduling, RT TLM monitoring, offline analysis,
**Facilities/Resources available:**
- Berkeley SSL MOC used for Mission Operations
- NERSC used for Level zero/higher level science data processing
- Sufficient communications bandwidth available at no cost to SNAP from both France and Japan ground station sites
- ~10 Mbps communications capability required from each remote ground site to Berkeley to satisfy latency requirements

## Mission/Science Operations Cost Basis of Estimate

**Mission Operations Cost Assumptions**
**Existing Berkeley SSL MOC serves as development basis**
**One additional equipment string costed for real-time support**
**Existing equipment strings can be used to provide hot backups, off-line test/maintenance function**
**Years costed for software development**
**Primarily to tailor existing Berkeley SSL MOC system to support SNAP mission**
**Bandwidth from France, Japan stations available at no cost to SNAP**
**No additional costs for Level 0/Science data processing (assume use of NERSC system)**
**Operations Staffing Cost Assumptions**
**First year (L-30 mos. to L-18 mos.): ****1.8 heads**** for ops planning activities**
**Second year (L-18 mos. To L-6 mos.): ****5.2 heads**** for development/test of ops products and plans**
**L-6 mos. to L+3:  ****9.5 heads**** for pre-launch ops rehearsals/sims, launch support, early orbit checkout, etc. **
**Nominal ****(6.3 heads)**** staffing level reached at L+12**

## Mission/Science OperationsAdditional Trades to Consider

**3 ground stations option**
- Add capability to store on-board full SNAP science bandwidth during gaps in coverage, with later downlink
- (+)  Increases percentage of data recovery
- (-)  Increases costs for C&DH and Mission Operations as a minimum.

## Mission/Science Operations Risk Assessment

**No risks identified**

## Mission/Science Operations Issues and Concerns

**No issues or concerns**

## Mission/Science OperationsBackup Charts

## Mission/Science Operations Driving Mission Characteristics

**Launch: October 2008**
**Mission lifetime: Nominal mission duration 2 years, with 5 year goal**
**Orbit overview: 19x57 Re**
**Space-Ground contacts:  **
**3 ground station option:  3 station contacts per day at Northern Latitude ground stations (Berkeley CA, Lyon France, Japan)**
**Data rates:**
**Average instrument data rate:  52 Mbps aggregate (assumes lossless compression and overhead)**
**Engineering/HK:  16 kbps (assumed****)**

## Mission/Science Operations Driving Mission Characteristics(cont.)

**Spacecraft summary:**
- CCSDS compliant
- 24 hours of on-board data storage for spectrometer and engineering data
**Operations summary:**
- No orbit adjustments necessary after commissioning
- Well defined instrument observations
- Sequence of targets uplinked to spacecraft every 4 days
- No target of opportunity observations envisioned.
- Majority of commanding is preplanned and is needed no more than once per day.
**Latency requirements: **
- 4 days to deliver raw telemetry from ground stations to NERSC for Level 0 and higher level data processing

## Support operations of SNAP satellite
Processing/display of real-time telemetry and status data
Spacecraft and instrument commanding
Attitude determination and orbit analysis 
HK Dump data receipt and processing for contingency
Ground Station (GS) scheduling
Engineering data analysis
Interact with ground station for satellite communications
Telemetry, command and status data
Electronic transfer of data to MOC/NERSC during each contact
Station scheduling
Voice communications

**Processing/display of real-time telemetry and status data**
**Spacecraft and instrument commanding**
**Attitude determination and orbit analysis **
**HK Dump data receipt and processing for contingency**
**Ground Station (GS) scheduling**
**Engineering data analysis**
**Interact with ground station for satellite communications**
**Telemetry, command and status data**
**Electronic transfer of data to MOC/NERSC during each contact**
**Station scheduling**
**Voice communications**

**Mission Operations****Driving Requirements**

## Mission OperationsDriving Requirements(cont.)

**Level 0 processing provided by National Energy Research and Scientific Computing Center (NERSC)**
**Architecture for Level 0 processing not provided or costed for this mission**
**Provide automation to facilitate reduced operations staffing, to include “lights-out” operations on weekday off-shifts and weekends**
**Automatically recognize alarm conditions and notify remote operations personnel during unstaffed operations**
**Automatically handle receipt of data dumps from GS’s and generation/delivery of Level 0 data products**

## Mission Operations Assumptions 

**“****Lights-Out” operations approach acceptable for normal operations to minimize operations costs**
**Satellite can nominally operate for up to 3 days without ground contact**
**Spacecraft and instruments autonomously manage health-and-safety (i.e., they will detect problems and safe themselves when necessary)**
**Typical Real-Time System Reliability, Maintainability, and Availability (RMA) is required **
**Hot backups needed for critical telemetry and command processors and provided as part of “infrastructure” available at Berkeley Space Science Laboratory (SSL)**
**Typical command constraint checking is sufficient **
**Minimal planning and scheduling needed given simplicity of spacecraft and instrument operations**

## Mission Operations Technologies Required

**MOC must be able to support the automated handling of specific functions/activities**
**Automatically process real-time data (housekeeping and science)**
**Automatically monitor telemetry, recognize error/alarm conditions, and notify offsite operations staff **
**Provide remote offsite operations personnel with remote access to data without violating security requirements**
**Automatically perform engineering analysis on housekeeping data**
- Generate trend plots, statistics reports, etc. for FOT analysis
- Recognize error/alarm conditions and notify remote operations personnel
**Berkeley SSL MOC contains all required technologies**

## Mission/Science Operations Subsystem Summary

**Technology Readiness Level: 8-9 (all required technologies have been at least demonstrated, most in currently operational systems)**
**Space-GND contacts: nominally 3 per day of 8 hours each at Northern Latitude ground stations (Berkeley, France, Japan)**
**Avg Aggregate Instrument Data Rate:  ~52 Mbps (includes lossless compression plus overhead)**
**Planning and Scheduling Requirements: Minimal**
**Science Data Processing Requirements:  Delivery science data to NERSC from ground stations with no more than 4 day latency**
**Technology Complexity: Minimal, currently available/operational technology proposed**
**Risk: Minimal **