[National Aeronautics and Space Administration]{.smallcaps}

[Goddard Space Flight Center]{.smallcaps}

­

![](media/image3.png){width="5.416666666666667in"
height="2.3020833333333335in"}

**EO-1**

**Operations Test Plan**

> January 15 , 1999

Note: Document updated often



**[Revision History]{.smallcaps}**

  ------------------ ------------------------ ----------------------------------------------------
                                              

  **Version 1**      Jerry Hengemihle email:  
  1/15/99            jerryh@microtel-md.com   
                     tel: 301-345-4005        

                                              

                                              

                                              
  ------------------ ------------------------ ----------------------------------------------------



**[Table of Contents]{.smallcaps}**

1\. Overview [1](#overview)

1.1. Scope [1](#scope)

2\. Applicable Documents [1](#applicable-documents)

2.1. Applicable Documents [1](#applicable-documents-1)

2.2. Reference Documents [2](#reference-documents)

3\. EO1 Mission Overview [Error! Bookmark not
defined.](#__RefHeading___Toc440719002)

4\. Operations Ground System Overview [Error! Bookmark not
defined.](#__RefHeading___Toc440719003)

5\. Operational Elements and Interfaces
[1](#operational-elements-and-interfaces)

6\. Launch Operations Concept [31](#launch-rehearsal-simulations)

7\. Relationship to Requirements [Error! Bookmark not
defined.](#__RefHeading___Toc440719006)

8\. Test Definition -- S, T, M [3](#test-definition-s-t-m)

9\. Top level Tests, Test Responsibilities, Test Dates
[4](#top-level-tests-test-responsibilities-test-dates)

9.1. Subsystem Validation Tests S --Tests
[4](#subsystem-validation-tests-s-tests)

9.2. Mission Readiness Tests (T-Tests)
[4](#mission-readiness-tests-t-tests)

9.3. Simulations (Category M) [4](#simulations-category-m)

10\. Key Dates from Swales I&T Plan [5](#key-dates-from-swales-it-plan)

10.1. Date MOC time Spacecraft Test Planned
[5](#date-moc-time-spacecraft-test-planned)

11\. Test Reporting and Discrepancies
[5](#test-reporting-and-discrepancies)

12\. Ground System Subsystem tests (S-Tests)
[7](#ground-system-subsystem-tests-s-tests)

12.1. S1 CGS Acceptance Test [7](#s1-cgs-acceptance-test)

12.1.1. Spacecraft simulator [32](#eo-1-spacecraft-simulator)

12.1.2. Command and Telemetry Test [7](#command-and-telemetry-test)

12.1.2.1. Telemetry [7](#telemetry)

12.1.2.2. Telemetry Data Archive [8](#telemetry-data-archive)

12.1.2.3. Commands [8](#commands)

12.1.2.4. STOL Processing [8](#stol-processing)

12.1.2.5. Terminal Display System [9](#terminal-display-system)

12.1.2.6. Command and Telemetry Data Base
[9](#command-and-telemetry-data-base)

12.1.2.7. Page Display Database [9](#page-display-database)

12.1.2.8. Automated Procedure Library [9](#automated-procedure-library)

12.1.2.9. Hard Copy Output [9](#hard-copy-output)

12.1.2.10. Access Control [10](#access-control)

12.1.2.11. Lights Out Operations [10](#lights-out-operations)

12.1.2.12. Command Management System (CMS) Test
[10](#command-management-system-cms-test)

• The CMS shall interface with the MOPSS to receive a daily activity
plan (DAP).
[10](#the-cms-shall-interface-with-the-mopss-to-receive-a-daily-activity-plan-dap.)

12.2. S2 MOPSS ATP [11](#s2-mopss-atp)

12.2.1. MOPSS Test Phases & Schedule [11](#mopss-test-phases-schedule)

12.2.2. Test Plan [11](#test-plan)

12.2.2.1. Version 1.0 [11](#version-1.0)

12.2.2.2. Version 1.1 [11](#version-1.1)

12.2.2.3. Version 2.0 [12](#version-2.0)

12.3. S3 Wallops Ground Station Testing
[12](#s3-wallops-ground-station-testing)

12.4. S4 FDSS ATP [13](#s4-fdss-atp)

12.4.1. Test No 1 [13](#test-no-1)

12.4.2. Test No 2 [13](#test-no-2)

12.4.3. Test No 3 [13](#test-no-3)

12.4.4. Test No 4 [13](#test-no-4)

12.4.5. Test No 5 [14](#test-no-5)

12.4.6. Test No 6 [14](#test-no-6)

12.4.7. Test No 7 [15](#test-no-7)

12.4.8. Test No 8 [15](#test-no-8)

S5 DPS ATP [17](#s5-dps-atp)

12.4.9. DPS Test Phases [17](#dps-test-phases)

12.4.9.1. DPS Release 1 Testing -- August 98
[17](#dps-release-1-testing-august-98)

12.4.9.2. WARP Format Test October 98 [17](#warp-format-test-october-98)

12.4.9.3. CCSDS Telemetry Processing Test December 98
[18](#ccsds-telemetry-processing-test-december-98)

12.4.9.4. Level 0 Processing [18](#level-0-processing)

12.4.9.4.1. ALI Level 0 Processing Test Feb 99
[18](#ali-level-0-processing-test-feb-99)

12.4.9.4.2. LAC Level 0 Processing Test Feb 99
[19](#lac-level-0-processing-test-feb-99)

12.4.9.4.3. Hyperion Level 0 Processing Test May 99
[19](#hyperion-level-0-processing-test-may-99)

12.4.9.5. Ground Station Interface Test
[20](#ground-station-interface-test)

12.4.9.5.1. X-band Tape Test Dec 99 [20](#x-band-tape-test-dec-99)

12.4.9.5.2. S-band Tape Test Dec 99 [20](#s-band-tape-test-dec-99)

12.4.9.5.3. S-band SAFS Test Dec 99 [20](#s-band-safs-test-dec-99)

12.4.9.6. SVF Interface Test Mar 99 [21](#svf-interface-test-mar-99)

12.4.10. DPS Test Schedule [21](#dps-test-schedule)

12.5. Year 2000 Testing [22](#year-2000-testing)

13\. Mission Readiness Tests (T-Tests)
[23](#mission-readiness-tests-t-tests-1)

13.1. T1 - MOC -- Spacecraft Interface Test
[23](#t1---moc-spacecraft-interface-test)

13.1.1. Pre-test configuration and documentation.
[23](#pre-test-configuration-and-documentation.)

13.1.2. Test Objectives [23](#test-objectives)

13.1.3. Test Personnel [24](#test-personnel)

13.1.4. Test Responsibilities [24](#test-responsibilities)

13.1.5. Spacecraft Configuration [25](#spacecraft-configuration)

13.1.6. Control Hand-over Protocol [25](#control-hand-over-protocol)

13.1.7. Test Reporting [25](#test-reporting)

13.1.8. Some Phone Numbers [26](#some-phone-numbers)

13.2. T2 Spacecraft -- MOC --MOPSS -- CMS -- FDSS Interface Test
[26](#t2-spacecraft-moc-mopss-cms-fdss-interface-test)

13.2.1. Spacecraft to MOC Interface [27](#spacecraft-to-moc-interface)

13.2.2. MOPSS to CMS [27](#mopss-to-cms)

13.2.3. CMS -- ASIST [27](#cms-asist)

13.2.4. CMS -- Spacecraft [27](#cms-spacecraft)

13.2.5. FDSS to MOPSS [27](#fdss-to-mopss)

13.2.6. FDSS to ASIST [27](#fdss-to-asist)

13.3. T3 Spacecraft -- MOC - MOPSS -- DPS - SVF Interface Testing
[28](#t3-spacecraft-moc---mopss-dps---svf-interface-testing)

13.3.1. Spacecraft to DPS [28](#spacecraft-to-dps)

13.3.2. DPS -- SVF [28](#dps-svf)

13.3.3. DPS -- MOPSS [28](#dps-mopss)

13.3.4. DPS -- ASIST [29](#dps-asist)

13.4. T4 RF Compatibility Test [29](#t4-rf-compatibility-test)

13.5. T5 MOC - Ground Stations Interface Test
[29](#t5-moc---ground-stations-interface-test)

13.6. T5.1 MOC -- TDRSS Interface Test
[29](#t5.1-moc-tdrss-interface-test)

13.7. T6 MOC -- WTR -- Interface Test [29](#t6-moc-wtr-interface-test)

14\. Mission Simulations (M-Tests) [30](#mission-simulations-m-tests)

14.1. M1 Normal Operations / Safehold Recovery Simulation
[30](#m2-normal-operations-safehold-recovery-simulation)

14.2. M2 Flight Timeline Simulation
[30](#m3-contingency-operations-simulation)

14.3. M3 L&EO Operations Simulation [31](#m1-leo-operations-simulation)

# Overview

## Scope

This document defines the Operations Test Plan for the NASA EO-1
program.

## Operational Elements and Interfaces

The operational elements of the EO1 mission are:

-   CGS Command/Telemetry Ground System

-   MOPSS Mission Operations Planning System

-   WGS Wallops Ground Stations

-   FDSS Flight Dynamics System

-   DPS Data Processing system

-   SVF Science Validation Facility

-   TDRSS Tracking and Data Relay Satellite System

-   EO-1 S/C EO-1 Spacecraft

-   EO-1 L/V EO-1 launch vehicle

-   FOT Flight Operations Team

The testing of the individual operational elements for application to
EO-1 flight operations and verification of the interactions and
interfaces between the elements is the intent of this document.

# Applicable Documents

## Applicable Documents

EO-1 Command and Telemetry Handbook (spec tbd)

EO-1 Detailed Mission Requirements (spec tbd)

Radio Frequency Interface Control Document Between the Earth Orbiter
(EO-1) Spacecraft and the Ground Network (GN) and the Space Network
(SN). January 1988

EO1 Space To Ground ICD

## Reference Documents

CCSDS 101.0-B-3: Telemetry Channel Coding. Blue Book. Issue 3. May 1992.

CCSDS 102.0-B-4: Packet Telemetry. Blue Book. Issue 4. November 1995.

CCSDS 201.0-B-2: Telecommand Part 1 \-- Channel Service. Blue Book.
Issue 2.

November 1995

CCSDS 202.0-B-2: Telecommand Part 2 \-- Data Routing Service. Blue Book.
Issue 2.

November 1992.

CCSDS 202.1-B-1: Telecommand Part 2.1 \-- Command Operation Procedures.
Blue

Book. Issue 1. October 1991.

CCSDS 701.0-B-2: Advanced Orbiting Systems, Networks and Data Links:

Architectural Specification. Blue Book. Issue 2. November 1992.

# Roles and Responsibilities

## GSFC Management

Dan Mandl -- Ground Systems Manager

Randy Harbaugh - Mission Readiness Manager

## FOT

Joe Howard \-- Lead FOT

Leo McConville

Alicia Cost

Seth Shulman

Bruce Trout

Tom Moore

Tom Berry

### Subsystems

Larry Alexander FEDS

Paul Garza Networks and Ground Stations

Jim Dowling ASIST

Bob DeFazio FDSS

Randy Harbaugh MOPSS

Rusty Whitman CMS

## Support

TBD Simulation Director

Jerry Hengemihle Test Planning

## Spacecraft

Earle Moyer I&T Manager

E.J.Bickley Test Conductor

Mark Perry Spacecraft Systems

# Test Definition -- S, T, M

Subsystem validation tests (S test) are performed on each individual
subsystem before any integrated tests are performed. These tests are
specifically used to test the hardware, software, and operability of the
elements of the ground system.

Integrated tests (T tests) test the interfaces between elements and the
specific interface requirements.

Simulations ( M tests) are tests where the primary objective is to train
or test the FOT. These can also accommodate testing system
functionality. Various types of simulations will be held at all stages
of pre launch operations.

# Top level Tests, Test Responsibilities, Test Dates

## Subsystem Validation Tests S --Tests 

> [Responsible Person]{.underline}

S1 1/99 CGS Acceptance Test Joe Howard

S2 1/99 MOPSS ATP Bruce Trout

S3 1/99 Wallops Ground Station Jim Henderson

S4 1/99 FDSS ATP Bob DeFazio

S5 1/99 DPS ATP Jerry Hengemihle

S6 1/99 Year 2000 Testing

## Mission Readiness Tests (T-Tests)

T1 11/98 Spacecraft -- MOC Interface Test

T2 1/99 Spacecraft -- MOC --MOPSS -- CMS -- FDSS Interface Test

T3 3/99 Spacecraft -- MOC - MOPSS -- DPS - SVF Interface Testing

T4 3/99 RF Compatibility Test

T5 6/99 MOC - Ground Stations Interface Test

T5.1 tbd MOC -- TDRSS Interface Test

T6 9/99 MOC -- WTR -- Interface Test

T7 10/99 Fully Integrated End-to-End System Test

Mission Readiness Test responsible persons

T1 Earl Moyer, Joe Howard

T2 Earl Moyer, Joe Howard, Bruce Trout, Bob Defazio

T3 E.Moyer, J,Howard, B.Trout, J.Hengemihle, L.Moy

T4 Earle Moyer, tbd

T5 Joe Howard, Jerry Hengemihle, Ralph Zimmerman

T5.1 Joe Howard, Jerry Hengemihle, Paul Garza

T6 Joe Howard, TBD

T7 EMoyer., TBD VDBG, TBD GS, J.Howard, B.Trout, Jerry H, L.Moy

## Simulations (Category M)

M1 4/99 Normal Operations / Safehold Recovery Simulation

M2 8/99 Flight Timeline Simulation

M3 8/99 L&EO Operations Simulation

M4 12/99 Launch Rehearsal

Mission Simulations Responsible persons

Spacecraft -- Moyer, Perry

MOC -- Howard, Trout

Ground Stations -- Jim Henderson

Networks -- Tom Russel

FDF -- Bob Defazio

Sim director - tbd

# Key Dates from Swales I&T Plan

Pre-Environmental Review 3/99

Pre-Ship Review 9/99

Flight Readiness Review 11/99

Schedule of MOC opportunities from Earle Moyer 10/5/98

## Date MOC time Spacecraft Test Planned

10/30 16 hrs Command & telemetry functional

11/25 24 hrs ACS software testing

3/10 20 hrs Comprehensive Performance Test

5/7 16 hrs CPT with flight ALI

5/31 tbd RF compatibility

6/3 16 hrs TB/TV orbit simulations

7/15 16 hrs CPT with SA installed

7/29 tbd RF compatibility

8/16 16 Hrs TV/TB orbit simulations

9/30 4 hrs MOC command and telemetry

# Test Reporting and Discrepancies

-   DR database maintained on EO-1 Web site

-   Discrepancy Reports

-   Opened by FOT

-   Assigned to subsystems -- subsystem leads will add to subsytem DR
    system if needed

-   Closed after retest

-   Open item status viewable via EO1 web-site

# Ground System Subsystem tests (S-Tests)

## S1 CGS Acceptance Test

This document defines the test plan for the EO-1 MOC Command and
Telemetry System (CTS). The CTS requirements will be met by the Combined
Ground System (CGS) provided by NASA GSFC code 581.

The CTS for flight operations is the same system being used for I&T. The
Flight Operations Team (FOT) is assisting with spacecraft I&T. The FOT
involvement with spacecraft I&T will allow the CTS to be tested during
I&T. The FOT will also gain useful knowledge of the spacecraft and will
lessen the need for special training.

### Command and Telemetry Test

The MOC -- Swales command and telemetry test will verify a large number
of the requirements allocated to the ASIST data system. For the most
part, the test procedures will be developed and debugged by the FOT for
use in spacecraft I&T.

The following requirements will be verified by this test.

#### Telemetry

-   The CTS shall process the EO-1 CCSDS channel access data units
    (CADUs) and virtual channel data units (VCDUs). Virtual Channels 0,
    1, and 2 shall be processed. VC0 is real-time spacecraft
    housekeeping. VC1 is playback spacecraft housekeeping from the
    onboard recorder. VC2 is playback spacecraft events.

```{=html}
<!-- -->
```
-   The CTS shall be capable of accepting and processing EO-1 telemetry.
    The EO-1 data rates and encoding formats are defined in the EO-1
    Space-To-Ground ICD

```{=html}
<!-- -->
```
-   The CTS shall provide data quality checking of the VCDUs and append
    quality information to each source packet.

```{=html}
<!-- -->
```
-   The CTS shall process and display and limit check EO-1 real-time
    data at rates up to 32 KBPS according to the specifications
    contained in the EO-1 project RDL data base. This includes
    conversion from raw to engineering units.

```{=html}
<!-- -->
```
-   The CTS shall provide the capability for viewing unformatted
    telemetry data.

```{=html}
<!-- -->
```
-   The CTS shall be capable of optionally checking any telemetry data
    item (analog or discrete) against a set of user definable limits and
    report limit violations.

```{=html}
<!-- -->
```
-   The CTS shall provide the capability to dump and verify the contents
    of each EO-1 flight processor memory, tables and stored command
    system. Additionally the system shall process messages generated by
    the flight software.

```{=html}
<!-- -->
```
-   The CTS shall provide S-band level-zero processing functions.
    Telemetry data shall be organized as time ordered files with all
    duplicate packets removed.

```{=html}
<!-- -->
```
-   The CTS shall be capable of short and long term statistical trending
    of telemetry data points. The time frame and data display format
    shall be user selectable.

#### Telemetry Data Archive

-   The CTS shall provide online and offline data storage for archiving
    telemetry data and shall provide a mechanism by which authorized
    users can retrieve stored data. The CTS shall provide a replay
    capability based on ground receipt time, or spacecraft time

```{=html}
<!-- -->
```
-   The archive shall be sized to store the last 120 days of spacecraft
    housekeeping data online.

```{=html}
<!-- -->
```
-   All EO-1 spacecraft data for the life of the mission shall be
    archived via offline data storage. Separate archives are to be
    maintained for each virtual channel/physical channel combination.

```{=html}
<!-- -->
```
-   The system shall maintain an online catalog describing the location
    of each archived data set and the spacecraft times of the data
    within each data set.

#### Commands

-   The CTS shall be capable of sending command data to the EO-1
    spacecraft via the ground stations at 2 kbps. The commands shall
    conform to the CCSDS COP-1 protocol and data formats as defined in
    the EO-1 Space-To-Ground ICD.

```{=html}
<!-- -->
```
-   The CTS shall maintain an online data set and printer log of all
    commands issued to the spacecraft

```{=html}
<!-- -->
```
-   The system shall maintain a list of critical commands that will
    require spacecraft controller approval prior to the sending of the
    command. The primary spacecraft controller must explicitly allow
    each of the critical commands to be forwarded to the spacecraft

```{=html}
<!-- -->
```
-   The system shall provide the capability to construct and send
    real-time commands.

```{=html}
<!-- -->
```
-   The CTS shall provide for the management and local editing of uplink
    code images for the onboard processors including the C&DH
    Mongoose-5, the WARP Mongoose-5, and the RSNs. The system shall be
    capable of maintaining multiple versions of the load images, naming
    each version so that it can be later referenced.

```{=html}
<!-- -->
```
-   The CTS will provide tools for the generation of stored command
    loads. The system shall provide tools that allow the user to
    generate absolute time sequences (ATS) and relative time sequences
    (RTS) from a language that is compatible with the on-line spacecraft
    controllers language.

#### STOL Processing

-   The system control language shall provide a capability to compose
    mathematical expressions of system variables in support of
    pre-launch and on-orbit activities, including functions of one or
    more variables, common unary and binary operators, and logical
    expressions.

```{=html}
<!-- -->
```
-   The system shall support the modularization and execution of
    subprocedures. The system shall support flow control expressions,
    such as unconditional branching, conditional branching and looping.
    The system shall support conditional, unconditional and timed waits
    (pauses in execution).

```{=html}
<!-- -->
```
-   The spacecraft controller shall have full interactive control in
    real time over the execution of procedures, including stop, start,
    abort, wait, branch and subprocedure execution.

#### Terminal Display System

-   The CTS shall be capable of displaying 6 pages on a single display.
    Operator command line displays, STOL procedure execution displays,
    telemetry pages, and event pages shall be displayed simultaneously.

```{=html}
<!-- -->
```
-   Display data fields shall be updated at a rate of 1 Hz using the
    latest telemetry values received from the spacecraft.

#### Command and Telemetry Data Base

-   The system shall provide a command and telemetry database facility
    for the definition, editing, display and configuration control of
    all EO-1 command and telemetry.

-   The command and telemetry definitions are to include packet formats,
    mnemonics, and engineering unit conversions.

-   database will support definition of onboard system tables.

#### Page Display Database

-   The system shall provide a page display database which shall be
    capable of holding at least 600 page display definitions.

-   The database shall support the definition of purely textual displays
    and mixed text and graphical displays.

-   The pages shall consist of a combination of text, strip, scatter,
    and graphical representations of any telemetry mnemonic, CTS
    variable, or derived data points.

#### Automated Procedure Library 

-   The system shall be capable of managing 2000 automated procedures.

-   The system shall provide a text editor in order to perform
    definition and modification of procedures.

-   The system shall provide a preprocessor which shall verify the
    structural content of procedures and preclude structurally incorrect
    procedures from being executed by the on-line system.

#### Hard Copy Output

-   The CTS shall provide at least one line printer.

-   CTS shall have the ability to print telemetry, derived data points,
    and operator generated events.

-   All commands sent to the spacecraft will be logged to the line
    printer

-   The CTS shall provide at least one page snap printer.

-   The CTS shall provide the capability to print screen dumps of
    displays, system events, print telemetry snapshots of any display
    page whether or not the specified page is active, and generate plots
    of operator selected data versus time.

#### Access Control

-   The CTS shall provide control stations and configured computer
    accounts for the set-up, operations and control of the CTS system.

-   Open/Closed network connections is TBD.

#### Lights Out Operations

-   The CTS shall provide support for lights out operations which
    includes autonomous handling of ground stations passes, autonomous
    monitoring of spacecraft health, and operator notification when
    problems are detected.

#### Command Management System (CMS) Test

The CMS test will verify the ground systems ability to accept input from
the MOPSS and to generate and upload for execution to the spacecraft
stored command loads sufficient to operate the EO1 autonomously. The
configuration for the CMS test is shown in the figure below:

The requirements verified by the CMS test are the following:

##### The CMS shall interface with the MOPSS to receive a daily activity plan (DAP).

-   The CMS shall compile the DAP to produce stored command uploads.

-   The CMS shall perform command constraint checking. The CMS shall
    provide the capability to edit constraint definitions.

-   The CMS shall provide for operator edits of SCP loads.

-   The CMS shall allow events to be defined. Examples in South Atlantic
    Anomaly zone crossing, ground station pass, apogee, etc.

-   The CMS shall accept and utilize a constants file.

## S2 MOPSS ATP

The MOPSS will be developed and tested in an incremental fashion.
Capabilities will be added as needed eventually producing the final
system to be used for flight. The MOPSS test phases are described in
section 3.1. The test schedule is given is section 3.2.

#  {#section .unnumbered}

### MOPSS Test Phases & Schedule 

The MOPSS will be released in three phases; Version 1, 1.1, & 2. Testing
of the incremental capabilities will be test with each release.

Test Schedule

MOPSS Release 1 Test 8/98

MOPSS Release 1.1 Test 10/98

MOPSS Release 2 Test 12/98

### Test Plan

#### Version 1.0

This release will test the following capabilities:

-   Ingest and display FDF orbital predicts

-   Allow operator key in of TDRSS and GS event schedule

-   Schedule activities/commands relative to orbital/GS/TDRSS events

-   Allow user to block out periods when imaging is not allowed

-   Ensure nadir imaging is not scheduled during black out periods

-   Provide capability to view and modify EO1 timeline

-   Provide capability to build an activity plan reflecting timeline

-   Provide capability to schedule activities relative to events

-   Allow for the user to manually schedule activities/commands

-   Provide file management activities -- over lapping data products,
    products updates, etc.

-   Allow user to browse and modify auxiliary data for
    events/activities, etc.

-   Provide feedback to the operator when constraints or conflicts occur

-   Basic report generation support

#### Version 1.1

This release will test the following capabilities:

-   Support ingest and display of SVF provided ground image scene
    request

-   Allow user definition/edit of scene requests

-   Support calculation and display image times based on requested
    scence lovcation and predicted EO1 orbit position

-   Schedule activities relative to image events

-   Ingest FDF generated maneiuver plan and command sheet

-   Schedule orbit maneuver related sequences

-   Provide capability to create an updated activity plan

#### Version 2.0

This release will test the following capabilities:

-   Display, allow selection, and transmit GS schedule from WSG

-   Receive and display GS schedule from WSG

-   Support ingest and display of cal scene requests

-   Automatically 'select' images and schedule image related commands

-   Interface w/FDF algorithms to schedule activities/commands for
    momentum management and attitude maneuvers for nadir and cal images.
    Note that different interface for nadir and cal images.

-   Assign WARP file Ids for each data stream to be stored for each DCE

-   Generate and image summary report which lists attributes of each DCE
    (time, location, DCE type, data streams stored, file Ids, DCE #,
    etc.

-   Perform resource utilization checks (WARP memory available,
    instrument on time, etc.)

-   Verify WARP file Ids correlate to DCE, DCE type, and data stream
    type (ex. MS/PAN dark cal, MS/PAN int cal, MS/PAN image, etc.)

-   Verify each WARP file ID assigned a unique number

-   Provide momentum management/attitude maneuver related constrint
    checking

-   Enhanced report generation support

## S3 Wallops Ground Station Testing 

## S4 FDSS ATP

### Test No 1

-   Accept attitude telemetry (including GPS data) into the EO1ADS
    telemetry processor from ASIST (D)

-   Accept real time attitude telemetry into EO1RTADS from ASIST. (D)

-   Generate OBC attitude validation reports and transfer to the MOC (D)

-   Extract GPS Single Point Solutions (SPS) from telemetry during every
    working day or when required. SPS data will be smoothed on the
    ground to provide an EO-1 orbit when needed. (1.3-7.2)

-   Extract raw GPS data from telemetry for early orbit validation of
    the

-   on-board GPS orbit determination. (1.3-7.3)

### Test No 2

-   Perform ground validation of the on-board attitude from the
    Autonomous Star Tracker (AST) via playback data. (1.3-1.3)

-   Perform ground estimates of true attitude, gyro biases via real time
    telemetry. (1.3-1.4)

-   Generate real time attitude displays in the MOC. (D)

-   Generate the attitude history file and prepare it for usage in FDSS
    applications software (D)

### Test No 3

-   Provide engineering data for attitude maneuver command inputs.

-   (1.3-3.4)

-   Provide predicted momentum management command inputs for

-   imaging periods. (1.3-4.4)

-   Provide instrument calibration command inputs. (1.3-4.5)

-   Perform computations for instrument alignment support. (1.3-3.1)

-   Perform sensor, star tracker, and gyro calibration, including
    estimates of alignments, biases and scale factors. (1.3-2.1)

-   Provide OBC up-linked input table parameters for alignment and
    calibration. (1.3-4.2)

-   Prepare calibration and attitude command and control products for
    transmission to FORMATS/MOPSS and/or the MOC. (D)

-   Transmit calibration and attitude command and control products to
    FORMATS/MOPSS and/or the MOC. (D)

### Test No 4

-   Generate the X band phased array station inviews data. (1.3-4.1)

-   Generate predicted sun/moon interference to the AST. (1.3-4.6)

-   Generate science planning aids for scheduling of co-fly images taken
    with Landsat-7. (1.3-9.8)

-   Generate planning aids for meeting constraints required for
    instrument calibration maneuvers and corresponding command
    generation data.

-   (1.3-4.5)

-   Prepare attitude utilities to generate products for transmission to
    FORMATS/MOPSS and/or the SVF. (D)

-   Transmit products from attitude utilities to FORMATS/MOPSS and/or
    the SVF. (D)

### Test No 5

-   Accept launch vehicle state vector from WTR in PODS. (D)

-   Smooth SPS on the ground to provide an EO-1 orbit when needed.

-   (1.3-7.2)

-   Validate on-board GPS orbit determination solutions using ground
    based

-   S-band tracking. (1.3-7.4)

-   Provide post-maneuver orbit determination with GPS or S band ground
    based tracking. (1.3-6.8)

-   Provide backup orbit determination using S-band tracking data from
    GN ground stations. (1.3-8.1)

-   Accept S-band tracking data from the ground stations for
    pre-processing. (D)

```{=html}
<!-- -->
```
-   Provide pre-processing for S-band tracking data when it is received
    in the MOC (1.3-8.2)

```{=html}
<!-- -->
```
-   Validate the EO-1 OBC orbit propagation. (1.3-7.8)

### Test No 6

-   Generate OBC orbit validation report and transfer to the MOC. (D)

-   Provide tracking data evaluation for S-band tracking during early
    orbit

-   (not performed in the MOC). (1.3-8.3)

-   Accept launch vehicle state vector from WTR in AUTOCON-G. (D)

-   Generate both an EO-1 and a Landsat-7 10 day predictive ephemeris
    (old Code 500 format) with planned maneuvers and transfer to the
    MOPSS.

-   (1.3-7.6)

-   Generate an EO-1 6 week predictive ephemeris (old Code 500 format)
    with planned maneuvers and transfer to the MOPSS. (1.3-7.7)

-   Convert AUTOCON-G ephemerides if necessary to make them compatible
    with FDSS product generation modules (D)

-   Generate EO-1 maneuver plans required to maintain the co-fly
    requirement with Landsat-7. (1.3-5.3)

-   Generate the maneuver planning file and transfer to FORMATS/MOPSS.
    (D)

-   Generate the maneuver command file and transfer to FORMATS/MOPSS.
    (D)

-   Perform post-maneuver calibration of all delta-V maneuvers.
    (1.3-6.7)

-   Generate a post-maneuver evaluation report for the FOT. (D)

-   Accept the Landsat-7 state vector from the Landsat-7 MOC. (1.3-7.5)

```{=html}
<!-- -->
```
-   Accept the Landsat-7 maneuver file from the Landsat-7 MOC. (1.3-7.5)

-   Provide mission analysis studies including; trajectory design
    analysis, mission propellant budget, launch window, and end-of-life
    analysis.

-   (1.3-5.1)

-   Design a post orbit insertion strategy to place the spacecraft in
    its mission orbit. (1.3-5.2)

-   Design an operational orbit plan to meet the co-fly imaging
    requirements with Landsat-7. (1.3-5.3)

-   Provide post orbit insertion orbit maneuver support to achieve /
    maintain proper phasing with Landsat-7. (1.3-6.2)

-   Provide orbit maneuver support to achieve / maintain a frozen and
    sun-synchronous orbit for EO-1. (1.3-6.3)

-   Provide orbit maneuver support to maintain ground track control for

-   EO-1. (1.3-6.4)

-   Provide orbit maneuver support for EO-1 inclination maneuvers to
    maintain the required MLT at the descending node. (1.3-6.5)

-   Perform orbit evolution analysis for EO-1 and Landsat-7 to determine
    future delta-V burn scenarios. (1.3-6.6)

### Test No 7

-   Accept AUTOCON-G ephemerides in STK and STK utilities for product
    generation. ( D)

-   Generate predicted ascending and descending node crossing times and
    longitudes. (1.3-9.1)

-   Generate predicted South Atlantic Anomaly entrance and exit times.

-   (1.3-9.2)

-   Generate predicted satellite shadow entrance and exit times.
    (1.3-9.3)

-   Generate predicted sub-satellite point shadow entrance and exit
    times.

-   (1.3-9.4)

-   Generate predicted ground station inviews. (1.3-9.5)

-   Generate the sun angle for power monitoring. (1.3-9.6)

-   Generate acquisition data for the ground stations and the NCC.
    (1.3-9.7)

-   Generate Extended Precision Vectors (EPVs) for both EO-1 and

-   Landsat 7 for uplink to the EO-1 spacecraft. (1.3-9.9)

-   Generate ground track data. (1.3-9.10)

-   Generate predicted Mean Local Time for ascending and descending
    nodes crossing times. (1.3-9.11)

-   Generate predicted entry and exit times for miscellaneous zones of
    exclusion. (1.3-9.12)

-   Generate solar array lunar eclipse entry and exit times. (1.3-9.13)

-   Generate sun angles at WRS scene centers. (1.3-9.14)

-   Capture forecast scheduling file from WOTIS and provide to
    FORMATS/MOPSS. (1.3-9.15)

-   Generate EO-1 TDRS inviews data for special coverage periods. (D)

-   Prepare STK products for transmission to FORMATS/MOPSS. (D)

-   Transmit STK products to MOPSS, ground station, and the NCC where

-   applicable. (D)

### Test No 8

-   Provide procedure for transfer of SLP file from the FDF to the FDSS
    in the MOC. Test procedure. (D)

-   Provide procedure for transfer of the Time Conversion Coefficients
    file from the FDF to the FDSS in the MOC. Test procedure. (D)

-   Provide procedure for transfer of JPL Export Ephemeris file from JPL
    to the FDSS in the MOC. Test procedure. (D)

-   Provide procedure for updating environmental files required by

-   AUTOCON-G and PODS. Test Procedures. (D)

-   Accept the attitude maneuver notification report from ASIST. (D)

-   Accept pre-maneuver pressure and temperature data from ASIST. (D)

-   Accept the post-maneuver ACS data from ASIST. (D)

-   Accept the post-maneuver pressure and temperature data from ASIST.
    (D)

-   Accept the cloud prediction report from NOAA. (D)

-   Obtain Landsat-7 state vector and a Landsat-7 maneuver plan from the

-   Landsat-7 MOC every working day. (1.3-7.5)

-   Verify the FDSS' ability to operate autonomously or in a scripted
    mode.

-   \(D\)

## S5 DPS ATP {#s5-dps-atp .unnumbered}

The DPS will be used extensively during spacecraft I&T to verify
spacecraft functionality including the WARP, X-Band transmitter, and the
instruments. Additional tests are needed to verify the end-to-end data
transfers via the ground stations. These tests are TBD until a
knowledgeable and responsible ground system representative is
identified.

The DPS will be developed and tested in an incremental fashion.
Capabilities will be added as needed eventually producing the final
system to be used for flight. The DPS test phases are described in
section 19.1. The test schedule is given is section 19.2.

### DPS Test Phases

#### DPS Release 1 Testing -- August 98

The first release of the DPS software will be tested on a FEDS
workstation set up in the EO1 Mission Operations Center (MOC) located in
building 14 at Goddard Space Flight Center (GSFC). This test will verify
the Flight Operations Teams ability to execute the programs comprising
release 1 of the DPS software. This test will use data files as input
generated by Edwin Fung of the WARP test team. The input data files will
consist of the anticipated output of the WARP given a known data pattern
as input (to the WARP). Additional datafiles provided by Edwin will be
used to verify the descrambling of the data bands testing the code
provided by MIT. *What about LAC and Hyperion?*

The DPS release 1 software will verify the following:

The DPS will process data as formatted by the EO-1 Spacecraft WARP data
system. The WARP data formats are defined in the EO-1 Space-To-Ground
ICD.

*The DPS shall be able to do the following front-end processing*

-   *ingest CADU formatted data.*

#### WARP Format Test October 98

The WARP GSE will capture the WARP output and store the data to disk.
These files will be transferred to the DPS for processing. The WARP
output will be captured both encoded and unencoded from either I or Q
data channels in a non-bit interleaved fashion. The DPS will process the
data files. The results will be manually inspected to verify the output
is as expected. The WARP data inputs will be designed using ramping data
patterns to allow easy detection of data dropouts, misordering, etc.
This testing will verify the following DPS requirements:

The DPS will process data as formatted by the EO-1 Spacecraft WARP data
system. The WARP data formats are defined in the EO-1 Space-To-Ground
ICD.

*The DPS shall be able to do the following front-end processing*

-   *decode Reed Solomon data*

-   *derandomize data*

-   *ingest CADU formatted data.*

#### CCSDS Telemetry Processing Test December 98

This phase will verify the DPS processing of WARP data which has been
stored to AMPEX tape and replayed. A subset of the tests run in WARP
functional testing will be checked. A high speed AMPEX tape recorder
will be used during Spacecraft I&T to record high speed WARP and X-Band
data. The data will be bit interleaved by TBD equipment to simulate the
ground station bit interleaving of the X-band data. The data will be
replayed into the DPS for procesessing.

> This test will verify:

The DPS will process data as formatted by the EO-1 Spacecraft WARP data
system. The WARP data formats are defined in the EO-1 Space-To-Ground
ICD.

*The DPS shall be able to do the following front-end processing*

-   *decode Reed Solomon data*

-   *derandomize data*

-   *ingest CADU formatted data.*

This test will also verify the ability of the DPS to read data from the
AMPEX tape

#### Level 0 Processing 

##### ALI Level 0 Processing Test Feb 99

After integration of the ALI onto the EO1 spacecraft, the ALI will be
set in a mode to output known data to the WARP. This data will be
recorded and replayed by the WARP. The replay data will be stored onto
AMPEX tape and replayed into the DPS. The DPS will process the data.
This test will verify:

The DPS will process image data from the Advanced Land Imager (ALI)
Instrument. The ALI data formats are defined in the ALI to WARP ICD.

*The DPS shall be able to process the files containing the ALI
housekeeping data taken during the image. These files will be recorded
on the AMPEX tape.*

*The DPS shall create an imageable PAN file as follows:*

-   *Reorder odd/even pixel offset*

-   *Extract the scan lines and place in band sequential order*

-   *Provide identifiable fill for those portions of a PAN line that do
    not have data (might to reword this)*

*The DPS shall process the MS file as follows:*

-   *Descramble the pixels*

-   *Extract the scan lines and place in band sequential order*

-   *Perform odd/even pixel reordering for bands 1, 1', 2, 3, 4, 4'*

-   *Perform correction for HgCdTe sampling for bands 5, 5' and 7*

-   *Provide identifiable fill for those portions of a MS line that does
    not have data*

*Each Data Collection Event (DCE) which is a set of the above processed
files, shall have an associated start and stop image time which is
derived from the housekeeping file.*

*The DPS shall have the following displays. (TBD)*

-   *Provide a quicklook display to indicate \# of scan lines processes
    or some other indication of progress*

*The DPS shall respond to the following error conditions:*

-   *Drop out in data on the AMPEX tape*

-   *Process frames that have RS errors, however mark the data which
    came from those frames.*

-   *In the case of sequence errors, the following should be done (TBD)*

*The DPS shall generate image report for each image*

-   *\# of search , check , lock flywheel frames*

-   *dropouts*

-   *gaps*

-   *other errors*

##### LAC Level 0 Processing Test Feb 99

After integration the LAC will be set in a mode to output known data to
the WARP (*whether or not the LAC has this capability is TBD*). This
data will be recorded and replayed by the WARP. The replay data will be
stored onto AMPEX tape and replayed into the DPS. The DPS will process
the data. This test will verify:

*The DPS will process data from the LEISA Atmospheric Corrector
Instrument (LAC). The LAC data formats are defined in TBD ICD.*

*The DPS shall process the LAC file as follows:*

-   *Band order the scan lines for 250 bands*

-   *The output of each detector shall be put into separate files that
    can later be assembled into a complete image.*

*The DPS shall be able to process the files containing the LAC
housekeeping data taken during the image. These files will be recorded
on the AMPEX tape.*

*Each Data Collection Event (DCE) which is a set of the above processed
files, shall have an associated start and stop image time which is
derived from the housekeeping file.*

##### Hyperion Level 0 Processing Test May 99

After integration the Hyperion will be set in a mode to output known
data to the WARP (*whether or not the Hyperion has this capability is
TBD*). This data will be recorded and replayed by the WARP. The replay
data will be stored onto AMPEX tape and replayed into the DPS. The DPS
will process the data. This test will verify:

*The DPS will process data from Hyperion Instrument . The Hyperion data
formats are defined in TBD ICD.*

*The DPS shall process the Hyperion file as follows:*

-   *Band order the scan lines for tbd bands*

-   *The output of each detector shall be put into separate files that
    can later be assembled into a complete image.*

*The DPS shall be able to process the files containing the Hyperion
housekeeping data taken during the image. These files will be recorded
on the AMPEX tape.*

*Each Data Collection Event (DCE) which is a set of the above processed
files, shall have an associated start and stop image time which is
derived from the housekeeping file.*

######  {#section-1 .unnumbered}

#### Ground Station Interface Test

##### X-band Tape Test Dec 99

What we need to verify is that the data put on the tape can be read
back, and identified. Any ground station info put on the tape needs to
be tested.

Ideally, we would put the output of the WARP into the ground station
receiver. The input to the WARP would contain known data which we can
verify after processing by the DPS. This verification might be manual,
or a file compare or a program which checks the data (this is TBD).

##### S-band Tape Test Dec 99

The ground station would make a data tape and we will send to GSFC. This
test needs to be repeated for the S-Band backup mode via tape because
the S-band takes a different data path. It's also anticipated that
images will be spread across multiple passes and we need to verify that
the DPS can handle a single image dumped on different ground station
passes.

##### S-band SAFS Test Dec 99

An electronic check of the S-Band backup mode transferring data
electronically via the SAFS system also needs to be done. This test
should be performed via both SGS and Wallops ground stations. This mode
will probably be used for early orbit aliveness and functional checks of
the instruments and the WARP.

#### SVF Interface Test Mar 99

The DPS will generate a DLT tape of the level 0 processed data. The SVF
will process the level 0 data to verify:

-   *DPS shall process the input files and create TBD HDF formatted
    files; four files for PAN, TBD files for Hyperion, and three files
    for the LAC and housekeeping data.*

-   *The DPS shall create an imageable PAN file as follows:*

a.  *Reorder odd/even pixel offset*

b.  *Extract the scan lines and place in band sequential order*

c.  *Provide identifiable fill for those portions of a PAN line that do
    not have data (might to reword this)*

-   *The DPS shall process the MS file as follows:*

a.  *Descramble the pixels*

b.  *Extract the scan lines and place in band sequential order*

c.  *Perform odd/even pixel reordering for bands 1, 1', 2, 3, 4, 4'*

d.  *Perform correction for HgCdTe sampling for bands 5, 5' and 7*

e.  *Provide identifiable fill for those portions of a MS line that does
    not have data*

-   *The DPS shall process the Hyperion files as follows: TBD*

-   *The DPS shall process the LAC file as follows:*

a.  *Band order the scan lines for 250 bands*

b.  *The output of each detector shall be put into separate files that
    can later be assembled into a complete image.*

-   *Each Data Collection Event (DCE) which is a set of the above
    processed files, shall have an associated start and stop image time
    which is derived from the housekeeping file.*

-   *The DPS shall place the processed files on a DLT tape.*

> *- Session per tape (TBD)*
>
> \- The files shall also be available for FTP

### DPS Test Schedule

DPS Release 1 Test 8/98

WARP Formatting Test 10/98

CCSDS Telemetry Processing Test 11/98

ALI Level 0 Processing Test 2/99

LAC Level 0 Processing Test 2/99

Hyperion Level 0 Processing Test 5/99

Ground Station Interface Test 12/98

SVF Interface Test 3/99

##  Year 2000 Testing

Each individual element of the EO1 mission as listed in section 5 will
be responsible for testing the individual element for year 2000
compliance. No integrated EO-1 (T or M tests) tests are planned for year
2000 compliance.

# Mission Readiness Tests (T-Tests)

## T1 - MOC -- Spacecraft Interface Test

Test T1 will verify the Spacecraft to MOC command and telemetry
interfaces. The planned configuration for this test is to have the MOC
equipment located at GSFC building 14 monitor and control the EO1
spacecraft located at Swales in Beltsville, MD. The schedule for test T1
is December 22,1998 at 19:00 GMT (2:00pm). The anticipated duration of
the test is 3 Hours.

### Pre-test configuration and documentation. 

Activities to occur the morning of 12/22.

-   Swales will provide the EO-1 spacecraft database to the MOC.

-   Swales will place the flight software used during the MOC to
    spacecraft interface test under configuration control. The
    configured software version numbers shall be documented by Swales.
    The configured version numbers shall be documented by the FOT as
    part of the test report.

-   The ASIST team will place the ASIST software to be used for the test
    under configuration control. The configured version numbers shall be
    documented by the FOT as part of the test report.

### Test Objectives

The primary objectives of test T1 will be to verify the following:

1.  **The physical hardware** in the MOC. .

2.  The **ASIST/FEDS software** capability to control the EO1 spacecraft
    from GSFC building 14 using remote connections to the spacecraft.
    The remote connections are required during MOC Mission Readiness
    Tests, Mission Simulations, and flight operations.

3.  The following capabilities are primary objectives for test T1:

-   Telemetry at 2 KBPS, 32 KBPS -- MOC telemetry processing
    verification

-   CCSDS packet commands

-   Bypass Commands

-   Special Commands

-   COP-1 command protocol

-   SSR Event dump

-   M5 Memory load & dump

-   M5 table load & Dump

4.  The following capabilities are secondary objectives for test T1:

-   RTS load -- real command sequence which simulates output from CMS

-   Telemetry at 1 MBPS

-   SSR Dump and post pass processing

-   RSN memory load and dump

**Test Restrictions**

The FOT will NOT send commands to switch power services on the
spacecraft. The powered state of the spacecraft will not change during
the test.

### Test Personnel

Swales will provide a test conductor (E.J.Bickley) and an electrical
system lead (Bruce Zink) to monitor the MOC testing at Swales.

The FOT will provide a primary test conductor (Joe Howard) and backup
test conductor (Alicia Kost) at the MOC.

The ASIST team will provide a FEDS expert (Larry Alexander) at Swales, a
FEDS expert (Tim Ray) at the MOC, and an ASIST expert (Jim Dowling) on
call for support.

### Test Responsibilities

[Code/Organization/Person]{.underline} [Responsibility]{.underline}

Larry Alexander FEDS ground system

Tim Ray FEDS/ASIST at MOC

Jim Dowling ASIST user workstations -- on call

FOT/Joe Howard MOC lead Test Conductor

FOT/Alica Kost MOC Test Conductor

Swales/Earle Moyer Spacecraft configuration

Swales/E.J.Bickley Spacecraft Database / Spacecraft test conductor

Swales/Bruce Zink Spacecraft Electrical

ATSC/TriThai Network Connectivity

NASA/Dan Mandl Ground Systems & FOT management

### Spacecraft Configuration

Power via solar array simulator 28V direct power to power system
electronics (PSE).

Battery will not be on-line.

Spacecraft electronics powered:

-   PSE

-   S-band receiver

-   COMM RSN

-   M5 processor

-   ACE LVPC -- all services OFF

-   C&DH LVPC -- all services OFF

The spacecraft clock correlation factor will be set to GMT via the I&T
clock source. This accuracy is anticipated to be +/- 5 seconds.

The spacecraft telemetry rate will be commanded to 32kbps with RS,
pseudorandom, and rate ½ convolutional encoding.

### Control Hand-over Protocol

Voice communications will be established and verified using speaker
phones at both the MOC and SWALES. The connection will be maintained
throughout the test. Speaker phones will be muted except when
communications are needed.

Telemetry data flow will be established between SWALES and the MOC.

After telemetry flow and satisfactory telemetry processing at the MOC
are reported via voice communications, command hand-over will begin.

To hand-over commanding, SWALES sends command "UPL COP1 OFF" to initiate
blind commanding. The MOC sends command "UPL COP1 ON" to establish
commanding.

When commanding is returned to SWALES, SWALES sends command "UPL COP1
OFF" followed by UPL COP1 ON". This sequence will be issued in the event
the command link at SWALES needs to be re-established to handle either a
failed command link from the MOC or a spacecraft emergency.

### Test Reporting

A post test report will be generated by the FOT documenting the results.

The on-line EO-1 Discrepancy Report tracking system will be used to
record problems encountered for this test and all future MOC testing.
Problem reports will also be submitted to subsystem problem tracking
systems as needed (i.e. ASIST DR tracking system, Spacecraft problem
tracking system, MOPSS DR system, etc.).

### Some Phone Numbers

Larry Alexander 301-286-9686

Jim Dowling will be on call for ASIST problems during test

4570. pager 202-259-1370 home 301-589-3762

Joe Howard 301-286-9507

Earle Moyer (301)902-4318

Tim Ray 301-286-0581

Swales Test Conductor -- (301)902-4650 \-- EJ Bickley or Leo McConville

Swales secondary phone line (301)902-4207

Swales FAX 301-902-4599

MOC 301-286-2686

MOC secondary phone line -- not yet installed.

Here are the issues that needs to be completed:

-   FEDS software for remote commanding installed and tested at Swales
    and MOC.

For questions or comments regarding this test plan contact Jerry
Hengemihle via email at <jerryh@microtel-md.com> or telephone at
301-345-4005 or fax at 301-345-4007.

## T2 Spacecraft -- MOC --MOPSS -- CMS -- FDSS Interface Test 

Test T2 is the second ground system Mission Readiness Test. The Mission
Readiness Tests will verify the interoperability of the various ground
system elements. Test T2 includes the EO1 spacecraft, the ASIST/FEDS,
CMS, MOPSS, and FDSS. The inter-element interfaces will be verified by
this test. The planned configuration for this test is to have the MOC
equipment located at GSFC building 14 monitor and control the EO1
spacecraft located at SWALES.

Generally, this test is intended to verify the spacecraft housekeeping
data flows and the applicable requirements of the ground system.

The following interfaces will be verified:

Spacecraft -- MOC

CMS -- MOC

CMS -- Spacecraft

CMS -- MOPSS

MOPSS -- FDSS

FDSS - ASIST

### Spacecraft to MOC Interface

This will reverify the testing from test T1. Some additional command and
telemetry capabilities will be verified. Stored command loads and dumps,
recorder dumps and processing.

[Secondary]{.underline}

-   C&DH M5/WARP code patch or reload

-   RSN/Instrument code patch

-   Spacecraft clock verification

### MOPSS to CMS

This test will verify the ability of the MOPSS to generate an EO1 daily
activity plan(DAP). The test will verify the ability of CMS to ingest
the DAP in order to generate a stored command load for the EO1
spacecraft.

### CMS -- ASIST

This test will verify the ability of the ASIST to upload and verify
stored command loads generated by CMS.

### CMS -- Spacecraft

This test will verify the successful execution of the command load by
the EO1 spacecraft. The load will have originated in MOPSS as a DAP,
have been generated by CMS and uplinked via the ASIST/FEDS command
telemetry system.

### FDSS to MOPSS

This test will verify the ability of MOPSS to ingest and utilize
products from FDSS to generate a DAP. The FDSS products will include:

-   Prepare calibration and attitude command and control products for
    transmission to FORMATS/MOPSS

```{=html}
<!-- -->
```
-   Generate a maneuver command file and transfer to FORMATS/MOPSS

### FDSS to ASIST

This test will verify the ability of the ASIST to generate data products
needed by FDSS. The products include (tbd -- need input from Bob
Defazio).

-   Accept attitude telemetry (including GPS data) from ASIST

-   Extract GPS single point solutions from telemetry

-   Extract raw GPS data from telemetry to validate on-board GPS orbit
    determination

-   Process Star Tracker playback data

## T3 Spacecraft -- MOC - MOPSS -- DPS - SVF Interface Testing 

Test T3 is the third ground system Mission Readiness Test. The Mission
Readiness Tests will verify the interoperability of the various ground
system elements. Test T3 includes the EO1 spacecraft, the ASIST/FEDS,
MOPSS, FDSS, DPS, and SVF. The inter-element interfaces will be verified
by this test. The planned configuration for this test is to have the MOC
equipment located at GSFC building 14 monitor and control the EO1
spacecraft located at SWALES.

Generally, this test is intended to verify the science data flows and
applicable requirements of the ground system.

*Add a diagram showing the test configuration:*

The following interfaces will be verified:

Spacecraft -- MOC

MOPSS -- DPS

DPS -- SVF,ALI/MIT,LEISA, Hyperion/TRW/Stennis

ASIST -- DPS (tbd depends on S-band backup mode)

FDSS

### Spacecraft to DPS

This test will verify the ability of the DPS to accept spacecraft
generated X-band data. The data will be processed to level0+.

### DPS -- SVF

This test will verify the interface between the DPS and the SVF. Both a
DLT tape and an electronic interface will be verified.

### DPS -- MOPSS

*Is there an interface here? How does DPS know about DCE numbers?*

### DPS -- ASIST

*tbd*

## T4 RF Compatibility Test

Test T4 is the forth ground system Mission Readiness Test. The Mission
Readiness Tests will verify the interoperability of the various ground
system elements. Test T4 includes the EO1 spacecraft the ground station
compatibility test van.

## T5 MOC - Ground Stations Interface Test

Each ground station will be tested to verify readiness to provide the
command, telemetry, and tracking support as defined in the EO-1 DMR.

The Wallops scheduling system will be verified to insure all the
scheduling capabilities required by EO-1.

The Wallops SAFS system will be verified.

## T5.1 MOC -- TDRSS Interface Test

This test is intended to verify EO-1 telemetry communications via TDRSS.
Spacecraft telemetry data will be routed to the RF SOC (tbd), uplinked
to an operational TDRSS satellite, and routed via the TDRSS network to
the MOC.

Configuration codes will be provided to the TDRSS White Sands ground
station database to include the EO1 spacecraft and 2 kbps telemetry
data.

## T6 MOC -- WTR -- Interface Test

# This test is intended to verify voice and data communications between VAFB and the MOC. This test will be performed before the launch rehearsal -- test M4. {#this-test-is-intended-to-verify-voice-and-data-communications-between-vafb-and-the-moc.-this-test-will-be-performed-before-the-launch-rehearsal-test-m4. .unnumbered}

#   {#section-2 .unnumbered}

# Mission Simulations (M-Tests) {#mission-simulations-m-tests .unnumbered}

EO1 Operations plans 4 formal mission simulations to prepare the flight
operations team, for EO1 operations. The EO1 spacecraft team, the
instrument teams, and the EO1 project personnel will support the mission
simulations as needed. The EO1 mission simulations and their tentative
test dates are listed below:

M1 6/99 L&EO Operations

M2 7/99 Normal Operations / Safehold Recovery

M3 9/99 Contingency Operations

M4 11/99 Launch Rehearsal

## M1 L&EO Operations Simulation 

The first mission simulation (M1) will simulate the EO1 launch countdown
and early orbit operations. The estimated time duration of test M1 is 48
hours. The primary and secondary objectives for test M1 are as follows:

[Primary]{.underline}

-   Launch countdown command procedures and control from MOC

-   Launch simulation, separation and deployment verification

-   Spacecraft stabilization, power positive verification

-   On orbit spacecraft power on and checkout

```{=html}
<!-- -->
```
-   ACS system verification

-   Power system verification

-   C&DH system verification

-   GPS verification

-   WARP operations

-   On-orbit stored command loads and execution

-   Ground station interface verification

```{=html}
<!-- -->
```
-   Operations via pass limited command and telemetry links

[Secondary]{.underline}

-   tbd

## M2 Normal Operations / Safehold Recovery Simulation

The anticipated time needed for test M2 is 48 hours. The primary and
secondary objectives of test M2 are as follows:

[Primary]{.underline}

-   Safehold entry -- recovery procedure

```{=html}
<!-- -->
```
-   On orbit instrument power on and checkout

```{=html}
<!-- -->
```
-   Technology Validation procedures

-   Trending points and parameters

-   SVF interface / MIT interface / Stennis interface / TRW interface

[Secondary]{.underline}

-   Spacecraft and instrument team ground support equipment final
    readiness

-   Sufficient and timely MOC access to commands and telemetry via ASIST

## M3 Contingency Operations Simulation

The anticipated time needed for test M3 is 48 hours. The primary and
secondary objectives of test M2 are as follows:

[Primary]{.underline}

-   Contingency / Anomaly conditions

[Secondary]{.underline}

-   tbd

## Launch Rehearsal Simulations

The I&T team will participate in spacecraft I&T through the
comprehensive performance testing after delivery of the spacecraft to
the launch site at Vandenberg. A skeleton crew will remain at the launch
site. Final spacecraft tests, and procedures will be performed from the
MOC.

# EO-1 Spacecraft simulator

In addition to spacecraft I&T, a spacecraft simulator will be set up in
building 14 at GSFC. This simulator will be used for procedure and
flight software testing after launch. The spacecraft simulator will also
be used for Flight Software Maintenance.

## EO1 Spacecraft Simulator Overview

The EO1 spacecraft simulator will be used by the FOT to test commands,
telemetry processing , STOL procedures, the FOT database, operational
stored command uploads, and for operator training. An option to add a
generic RSN breadboard to the configuration allows the EO1 spacecraft
simulator to serve as a platform for flight software maintenance and
testing.

The major components are the following:

M5 breadboard

Virtual Sat

Command & Telemetry Simulator

Generic RSN breadboard (optional)

The Command and Telemetry Simulator (CTS) simulator will interface with
the MOC FEDS on one side and the M5 flight computer on the other. The
CTS will simulate the ground station interface to the FEDS and the EO1
COMM RSN interface to the M5 flight computer. In addition, the CTS will
simulate the WARP M5, WARP RSN, ALI RSN, LACE, Hyperion, HK RSN and the
PSE RSN. The CTS will accept commands and will generate telemetry for
each

spacecraft remote terminal.

The M5 breadboard is an exact duplicate of the flight computer used for
C&DH software development. The flight code version will be loaded into
the EEPROMS. This will give the S/C simulator an exact simulation of the
M5 flight computer.

The VirtualSat simulator will simulate the EO1 ACE electronics, the ACS
sensors and actuators, and the EO1 flight spacecraft dynamics.
VirtualSat is the same simulator used to test the EO1 ACS flight
software.

The optional generic RSN breadboard will provide additional capabilities
for exercising the generic capabilities of the RSN including memory and
table loads and dumps. This capability will be particularly useful for
flight software maintenance.

## Hardware elements:

The EO1 spacecraft simulator consists of the following hardware
elements.

1773 Star Coupler

M5 breadboard

Generic RSN breadboard (option)

VirtualSat:

PC

Condor single function card

Command Telemetry Simulator (CTS)

PC

Ethernet network card

SBS multi-function 1773 card

Miscellaneous

5V power supply

Test equipment rack or card cage (for breadboard and power supply)

Interconnecting cables

## Software Elements:

The EO1 simulator consists of 2 software CSCIs. The VirtualSat software
and the CTS software.

The VirtualSat software is provided by the Hammers Company. There is no
new development required.

The CTS software will be provided by tbd.

### VirtualSat Simulator Description

*To be provided.*

### EO1 CTS Software Description

The CTS will consists of four major components: the ground station real
time interface, the simulation user interface, the COMM RSN simulator,
and the generic remote terminal simulator.

####  Ground Station Interface

1\. Simulate the ground station interface as implemented in the ground
station PTP. The interface uses TCP/IP "sockets" transferring data
packets formatted using packet headers following the TRACE format. The
data format is specified in the EO1 Space to Ground ICD.

2\. The ground station interface will be capable of simulating real time
ground station passes of operator specified length. This simulation will
consist of the same real time data transfer capability as the ground
station PTP.

####  EO1 Spacecraft COMM RSN Simulation

1\. The COMM simulator will process the uplink data stream. This
processing will consist of:

-   Preamble detection

-   Sync detection

-   Codeblock verification

-   Codeblock packet formatting

-   Codeblock packet data transfer to M5 via 1773 data bus

4\. The COMM simulator will process the downlink data stream. This
processing will consist of:

-   VCDU packet reception from M5 via 1773 data bus

```{=html}
<!-- -->
```
-   VCDU packet formatting (PTP simuation)

-   VCDU time stamp

-   VCDU transfer to FEDS via tcp/ip socket interface

The COMM simulator will not simulate the following:

X-band data

2 Mbps S-band downlink \*\* may be an upgrade option

S-band Reed Solomon, convolutional, pseudorandom encode/decode

Ground station SAFS interface.

#### EO1 Spacecraft Remote Terminal Simulation

The CTS will simulate every EO1 remote terminal (except the ACE RSN).
The simulator will provide telemetry housekeeping data packets to the M5
flight computer. The simulator will accept commands from the 1773 data
bus. Invalid commands will be rejected and valid commands will be
accepted. The level of fidelity of command verification is TBD.

The remote terminal simulator will provide a user interface and a set of
generic utilities for defining the contents of telemetry data packets.
The generic utilities will include the following:

Definition of packet data formats.

Definition of static data packet values

Data values incrementing at specific times by specific amounts

Data values changing at specified times

Data values change based on receipt of a valid command packet.

The CTS simulator will be capable of maintaining a user defined powered
on configuration of each simulated remote terminal. Remote terminals
with powered off status will not respond to requests for telemetry and
will not process commands.

#### Simulation User Interface

The CTS user interface will provide for configuration of the following:

-   Powered status of EO1 remote terminals.

-   Telemetry packet definition

-   Simulation event scheduling

-   ground station passes

-   others event (tbd)

## CTS Software Design Requirements

The CTS software will be designed such that higher fidelity simulation
capabilities may be added at a later date. These design requirements
include:

-   High level programming language: C, C++, java, smalltalk, or Ada

-   Structured or object oriented design methodology