Attachment E - LandIS SIM RD- Rev A.pdf

LandIS Sim RD LNEXT-LANDIS-REQ-0010 Revision A ii

Landsat Next Landsat Instrument Suite (LandIS) Simulator Requirements Document (LandIS Sim RD)

Signature/Approval Page

Prepared by:

Electronic Signature in TDMS Approval Date in TDMS Adam Reardon Date Landsat Next Simulator Systems Lead Engineer Org./Code 597

Approved by:

Electronic Signature in TDMS Approval Date in TDMS Wen-Ting Hsieh Date Landsat Next Payload Manager Org./Code 426

Approved by:

Electronic Signature in TDMS Approval Date in TDMS James Pontius Date Landsat Next Project Manager Org./Code 426

Approved by:

Electronic Signature in TDMS Approval Date in TDMS Evan Webb Date Landsat Next Mission System Manager Org./Code 599 iii

CM Foreword This document is a Landsat Next Project Configuration Management (CM)-controlled document.

Changes to this document require prior approval of the applicable Configuration Control Board (CCB) Chairperson or designee. Proposed changes shall be submitted to the Landsat Next CM Office (CMO), along with supportive material justifying the proposed change. Changes to this document will be made by complete revision.

Questions or comments concerning this document should be addressed to:

NASA/Goddard Space Flight Center Landsat Next Project Office, Code 426 Attention: Configuration Management Office Greenbelt, Maryland 20771 iv

Change History Log v

List of TBDs/TBRs Hyperlink to TBx Location Summary Ind.

Name/Org.

Due Date

TBx-1 Section 2.4.3

The Launch Segment will provide the assets and services associated with the Launch Vehicle (LV) and the constellation-to-LV integration. This will include the LV; all Launch Vehicle-Ground Support Equipment (LV-GSE), property, and facilities to integrate the constellation to the LV and verify their integration; and prelaunch testing with ground-based functions. The launch vehicle and launch site are TBD. The three observatories comprising the Landsat Next constellation will be launched together on the same launch vehicle.

Launch Services Segment

(LSS)

MCDR

TBx-2 Section 3.1.2

LSim-276 The most recent 10 (TBR) minutes of housekeeping telemetry data shall be preserved.

Rationale: To capture the most recent housekeeping telemetry data for use in anomaly investigation. In the event of a failure of the flight computer (reboot of a flight computer) at least the most recent 10 (TBR) minutes of housekeeping telemetry data is preserved. Capability to preserve more than 10 (TBR) minutes of housekeeping telemetry data is acceptable.

Flight Software ISRR

TBx-3 Section 3.1.2

LSim-287 The LOpS shall generate an uncompressed imaging sensor data rate less than 1.8 (TBR) Gbps.

Command & Data

Handling

ISRR

TBx-4 Section 3.1.2

LSim-288 The LOpS shall be ready to generate imaging sensor data within 5 (TBR) seconds of receipt of command to capture imaging sensor data.

Command & Data

Handling

ISRR

TBx-5 Section 3.1.2.1

LSim-277 The instrument ancillary data stored with each instrument data block shall be time-correlated with the full image exposure plus (TBD) margin before and after the image.

Command & Data

Handling

ISRR

TBx-6 Section 3.1.8

LSim-149 LOpS shall allow the users to perform test in a "Test as you Fly" manner in which, once the Simulator is configured it can be operate without intervention for 120 hours (TBD).

Rationale: The LOpS needs to allow users to test uninterrupted for the duration of planned activities without operator intervention. The 120 hours (TBD) represents the expected duration of the long duration testing on the LOpS.

Mission Readiness ICDR

TBx-7 Section 4.1.2

LSim-290 The LOpS shall generate an uncompressed imaging sensor data rate less than 1.8 (TBR) Gbps.

Command & Data

Handling

ISRR

TBx-8 Section 4.1.2

LSim-291 The LOpS shall be ready to generate imaging sensor data within 5 (TBR) seconds of receipt of command to capture imaging sensor data.

Command & Data

Handling

ISRR

vi

Table of Contents SIGNATURE/APPROVAL PAGE ................................................................................................ II

CM FOREWORD ..........................................................................................................................III

CHANGE HISTORY LOG .......................................................................................................... IV

LIST OF TBDS/TBRS .................................................................................................................... V

TABLE OF CONTENTS .............................................................................................................. VI

LIST OF FIGURES ..................................................................................................................... VII

LIST OF TABLES ....................................................................................................................... VII

1.0 INTRODUCTION

1.1 Purpose

1.2 Scope

1.3 Related Documents

1.3.1 Applicable Documents

1.3.2 Reference Documents

1.3.3 Project Applicable Documents

2.0 MISSION OVERVIEW

2.1 Mission Statement

2.2 Mission Background

2.3 Mission Objectives

2.4 Mission Implementation

2.4.1 Space Segment

2.4.2 Ground Segment

2.4.3 Launch Segment

3.0 LANDIS OPERATIONS SIMULATOR (LOPS)

3.1 General

3.1.1 Mission Modes & States

3.1.2 Command and Data Handling (C&DH)

3.1.2.1 Ancillary Data

3.1.2.2 Imaging Sensor Data

3.1.2.3 Telemetry

3.1.2.4 Command Capability

3.1.3 Input and Output Data Buses

3.1.4 FSW & DB

3.1.5 Failure Response and Redundancy

3.1.6 Electrical Systems

3.1.7 Grounding

3.1.8 Simulator Operations

3.1.9 Operations Interface

3.1.10 Thermal

4.0 LANDIS INTERFACE SIMULATOR (LIS)

vii

4.1 General

4.1.1 Mission Modes & States

4.1.2 Command and Data Handling (C&DH)

4.1.2.1 Ancillary Data

4.1.2.2 Imaging Sensor Data

4.1.2.3 Telemetry

4.1.2.4 Command Capability

4.1.3 Input and Output Data Buses

4.1.4 FSW & DB

4.1.5 Electrical Systems

4.1.6 Grounding

4.1.7 Simulator Operations

4.1.8 Operations Interface

APPENDIX A ACRONYMS

APPENDIX B DEFINITIONS

List of Figures

Figure 2.4-1 Landsat Next Operations Concept (Generated from Landsat Next Common Mission Architecture Diagram LNEXT-SYS-DESC-0022 Rev -)

List of Tables

No table of contents entries found.

1.0 INTRODUCTION

1.1 PURPOSE

This specification serves to establish the requirements for the Landsat Next (LNext) Landsat Instrument Suite (LandIS) Operations Simulator (LOpS) and Interface Simulator (LIS) simulation capability. The requirements in this document define the capabilities of the LOpS and LIS in sufficient detail to enable their development for integration with a Spacecraft Simulator or Flight Spacecraft.

1.2 SCOPE

This specification establishes the requirements for the LOpS, and LIS to be integrated as elements of a combined Observatory Operations Simulator (OOpS), Integrated with the Spacecraft, or operated independently. Both the LOpS and LIS will have the flexibility to be operated in a stand-alone fashion to allow for development, testing, and training while not integrated with the larger systems. The LIS will be utilized at both the Instrument and Spacecraft vendors for risk reduction and system validation. The LOpS will be used for the duration of the Landsat Next program and will initially be available for use at the Instrument and Spacecraft vendors for risk reduction and system validation. The LOpS will be integrated with the Spacecraft Operations Simulator (SOpS) by the spacecraft vendor to form the OOpS. The LOpS usage will then migrate to the LNext Mission Operations Center (MOC) located at NASA Goddard where it will be used to support ground system testing, mission readiness activities, and long-term operations.

1.3 RELATED DOCUMENTS

1.3.1 Applicable Documents

Document Number Title Revision Section Reference

CCSDS 123.0-B-2 Low-Complexity Lossless and Near-lossless Multispectral and Hyperspectral Image Compression

Recommended Standard, Issue 2, Technical corrigendum 3

All

In this document, citations are assumed to be the latest version unless otherwise noted.

This document table was generated from the Landsat Next Common Reference and Applicable Documents List (LNEXT-MGMT-DESC-0008) DRAFT Rev C.

1.3.2 Reference Documents

Document Number Title Revision Public Law #105-303 “Commercial Space Act of 1998,” Public Law

#105-303, 112 Stat., 2843., H.R. 1702, 105th Congress, Adopted October 28, 1998

N/A

Public Law #102-555 “Land Remote Sensing Policy Act of 1992,” Public Law #102-555, 106 Stat. 4163., H.R.

6133, 102nd Congress, Adopted October 28, N/A

In this document, citations are assumed to be the latest version unless otherwise noted.

This document table was generated from the Landsat Next Common Reference and Applicable Documents List (LNEXT-MGMT-DESC-0008) DRAFT Rev C.

1.3.3 Project Applicable Documents

Document Number Title LNEXT-LANDIS-ICD-0001 Landsat Next Instrument Suite (LandIS) Interface

Requirements Document (IRD) LNEXT-LANDIS-REQ-0007 Landsat Next Landsat Instrument Suite (LandIS) Requirements

Document (LaRD) LSDS-2389 Landsat Next Design Reference Case – 18 Days (DRC-18)

Definition In this document, citations are assumed to be the latest version unless otherwise noted.

This document table was generated from the Landsat Next Common Reference and Applicable Documents List (LNEXT-MGMT-DESC-0008) DRAFT Rev C.

2.0 MISSION OVERVIEW

2.1 MISSION STATEMENT

Landsat Next, consistent with United States (U.S.) law and government policy, will continue the Landsat program's acquisition, archival, and distribution of multi-spectral imagery affording global, synoptic, and repetitive coverage of the Earth's land surfaces at a scale where natural and human-induced changes can be detected, differentiated, characterized, and monitored over time.

2.2 MISSION BACKGROUND

Following the successful launch of Landsat 8 (formally named Landsat Data Continuity Mission, LDCM) in February 2013, and during the development of Landsat 9, the United States Geological Survey (USGS) and National Aeronautics and Space Administration (NASA) recognized the need to assemble a team of experts from within both agencies to evaluate how to inform an acquisition strategy for the Landsat mission to follow Landsat 9. The NASA-USGS Joint Agency Sustainable Land Imaging (SLI) Architecture Study Team (AST) was formed in September 2018 and was tasked with investigating how to best satisfy the diverse set of user needs collected in the USGS “User Needs for the Sustainable Land Imaging Program – Release 2.0.” These investigations resulted in a set of recommendations to the headquarters of both agencies, delivered in December 2019. The highest-recommended “Roadmap 1” architecture described a small constellation of “superspectral” space-based sensors that would substantially improve the spectral, spatial, and temporal capabilities of previous Landsat missions, while continuing to satisfy the primary goal of ensuring a highly calibrated data set that maintains compatibility with the legacy data of the Earth’s land mass held in the National Satellite Land Remote Sensing Data Archive (NSLRSDA) at USGS’s Earth Resources and Observation Science (EROS) Center. In April 2020 NASA/Goddard Space Flight Center (GSFC) received authorization to initiate the Landsat Next project consistent with the AST’s Roadmap 1 recommendation.

The goal of Landsat Next is to continue the acquisition, archival, and distribution of multi-spectral imagery affording global, synoptic, and repetitive coverage of the Earth's land surfaces at a scale where natural and human-induced changes can be detected, differentiated, characterized, and monitored over time. This goal is in keeping with the Landsat programmatic goals stated in both the Commercial Space Act of 1998 (Public Law 105-303) and the Land Remote Sensing Policy Act of 1992 (Public Law 102-555). This policy requires that the Landsat Program provide data into the future that is sufficiently consistent with previous Landsat data to allow the detection and quantitative characterization of changes in or on the land surface of the globe.

Landsat Next continues the long-running partnership of NASA and USGS, with NASA providing the space and launch segments and USGS providing the ground system, providing the longest continuous global record of the Earth’s surface. The Landsat series of satellites have continuously acquired multispectral images of the global land surface since the launch of the Earth Resources Technology Satellite (ERTS, later renamed Landsat 1) in 1972. The Landsat data archive constitutes the longest continuous moderate-resolution record of the global land surface as viewed from space.

2.3 MISSION OBJECTIVES

Landsat Next has these major mission objectives:

• Collect and archive moderate resolution, Visible Through Short Wave Infrared (VSWIR) reflective and Thermal Infrared (TIR) emissive image data affording seasonal coverage of the global landmass for a continuous period of not less than five (5) years.

• Ensure that Landsat Next data are sufficiently consistent with data from the earlier Landsat missions in terms of relative acquisition geometry, calibration, coverage characteristics, spectral characteristics, output product quality, and data availability to permit studies and management of land cover along with land and water resource change over multi-decadal time periods.

• Ensure Landsat Next is responsive to critical emerging user needs and applications as characterized by periodic assessment, currently the User Needs for the Sustainable Land Imaging Program July 2018, Release 2.0, and identified by the operational requirements for collection, processing, archiving, and distribution of land surface data to the United States Government and other users.

• Distribute Landsat Next data products to the public on a nondiscriminatory basis.

2.4 MISSION IMPLEMENTATION

NASA and USGS each have specific responsibilities for Landsat Next and will deliver the major elements to the overall mission. NASA will provide the Space and Launch Segments of Landsat Next, and USGS will provide the Ground System and mission operations. NASA/GSFC will provide overall Landsat Next project management, mission system engineering, and mission assurance during development and will transition the mission to USGS following on-orbit commissioning.

The Landsat Next post-launch nominal mission operations concept is shown graphically in the Figure below.

Figure 2.4-1 Landsat Next Operations Concept (Generated from Landsat Next Common

Mission Architecture Diagram LNEXT-SYS-DESC-0022 Rev -)

2.4.1 Space Segment

NASA/GSFC will provide the Space Segment, which will consist of a constellation of three observatories flying in coordinated sun-synchronous orbits at 653km altitude, each with nominally identical spacecraft and instrument suites. The observatories will be equally spaced in the orbit, providing in aggregate a six-day ground repeat period at the equator.

The instrument suites will each provide 26 spectral bands with a maximum ground sampling distance of 10m-60m dependent on the spectral band, covering a swath on the ground of approximately 164km on a ground track defined by a world-wide reference system known as

WRS-3.

2.4.2 Ground Segment

The Landsat Ground Segment currently supports mission operations for Landsats 8 and 9.

Landsat Next takes advantage of developments on these missions and will upgrade and expand the current systems to accommodate Landsat Next. The Landsat Ground Segment consists of the Ground System (GS) and its external interfaces, including NASA institutional services. The GS includes the Mission Operations Center (MOC), the Ground Network (GN), and the Data Processing and Archive System (DPAS). External interfaces include NASA's Near Space Network (NSN) and Advanced Communications Capabilities for Exploration and Science Systems (ACCESS), GSFC Conjunction Assessment and Risk Analysis (CARA) and its Flight Dynamics Facility, along with other external interfaces.

The MOC provides the primary means to control and monitor the Landsat Next constellation.

The Landsat Next Flight Operations Team (FOT) at the MOC performs mission planning and scheduling, command and control, health and status monitoring, orbit and attitude maintenance, performance analysis, onboard memory management, and flight and ground software maintenance. The FOT utilizes MOC functionality to detect, investigate and resolve spacecraft anomalies and monitor the instrument image collections from the onboard constellation and generate special image collections. The MOC ingests, processes and archives data via the GN.

The GN includes geographically dispersed ground station resources for mission execution and includes both the Landsat Ground Network (LGN) and a wideband data routing capability, which transfers mission data to DPAS across wide area networks. The LGN provides communication capability for each observatory of the constellation for commanding and housekeeping data via the S-Band and will receive mission data from each observatory over a Ka-band downlink.

The DPAS ingests mission data from the GN, processes the mission data to form data products, and archives the data products (Level 0, Level 1R, Level 1Gs, Level 1T). The DPAS also provides a long-term archive capability for raw data and allows the user community to query, download, and directly interact in the cloud with Landsat Next data products, via a public-facing web portal for receiving data products. The DPAS is located at USGS Earth Resources Observation and Science (EROS) near Sioux Falls, South Dakota.

The USGS will lead overall Landsat Next GS development. The USGS will also lead integration of the GS and ensure timely completion of ground readiness testing in preparation for NASA-led mission readiness activities. The MOC will perform planning, scheduling, and observatory operations activities during Landsat Next mission readiness testing.

2.4.3 Launch Segment

The Launch Segment will provide the assets and services associated with the Launch Vehicle (LV) and the constellation-to-LV integration. This will include the LV; all Launch Vehicle- Ground Support Equipment (LV-GSE), property, and facilities to integrate the constellation to the LV and verify their integration; and prelaunch testing with ground-based functions. The launch vehicle and launch site are TBD. The three observatories comprising the Landsat Next constellation will be launched together on the same launch vehicle.

Sections 2.0-2.4.3 were generated using Landsat Next Common Boilerplate (LNEXT-MGMT- DESC-0005) Rev C

3.0 LANDIS OPERATIONS SIMULATOR (LOPS)

3.1 GENERAL

3.1.1 Mission Modes & States

LSim-1 The LOpS shall simulate LandIS operational modes and mode transitions.

Rationale: The LOpS mirrors the functionality of the flight Instrument. This includes responses from deployments, subsystem configurations, and power loading.

LSim-5 The LOpS shall initialize to a known, repeatable configuration upon application of Operational Power.

Rationale: This capability mirrors the functionality of the flight instrument. Need a basic engineering state to power on into and proceed to configure the instrument into its nominal science configuration.

LSim-11 The LOpS Simulator shall simulate Flight Instrument safe configuration upon detection of safing events.

Rationale: This capability mirrors the functionality of the Flight Instrument and is expected to respond to internal fault monitoring and configure the instrument into the same safe configuration as the flight instrument. Faults may also be induced via a user interface.

LSim-12 The LOpS stored number of missed time of day messages which result in safe configuration shall be alterable over the range of one (1) up to a maximum of 63 consecutive time of day messages.

Rationale: This capability mirrors the functionality of the Flight Instrument. Allowing the number of consecutive loss of time of day messages here allows for the duration of the communications outage to be varied before the instrument response. Assumes time of day messages are received at 1Hz.

LSim-13 The LOpS shall transition to a safe configuration upon loss of time of day messages with the spacecraft, with a persistence that is alterable per LSim- 12.

Rationale: The LOpS will replicate the flight instruments capability. Loss of time of day messages here is used as an indicator of loss of communications with the spacecraft bus. The instrument needs to be safe in this case without relying on communications with the spacecraft.

3.1.2 Command and Data Handling (C&DH)

LSim-17 The LOpS shall include a watchdog timer which is to reset the microprocessor after a specified interval of time, unless the timer is restarted.

Rationale: The operational flight software will periodically “pet” or restart the watchdog timer.

After being restarted, the watchdog will begin timing for another predetermined interval. The flight software may also force a processor restart by allowing the watchdog timer to expire.

LSim-20 The LOpS shall replicate flight design and use flight like parts to the first active circuit level, for all digital and analog signals that interface to the spacecraft bus.

Rationale: LOpS may need to connect to the Spacecraft and should use flight-like parts as stated in the requirement.

LSim-236 The LOpS Simulator shall replicate Instrument internal timing with respect to the time-of-day time code message and time-of-day 1PPS signal, as defined in LandIS Interface Requirement Document (LIRD) (LNEXT-

LANDIS-ICD-0001).

Rationale: The LOpS may be integrated with the flight SC and will need to have timing that matches the LandIS flight unit to identify any potential issues with the interface

LSim-276 The most recent 10 (TBR) minutes of housekeeping telemetry data shall be preserved following a processor reset/restart.

Rationale: To capture the most recent housekeeping telemetry data for use in anomaly investigation. In the event of a failure of the flight computer (reboot of a flight computer) at least the most recent 10 (TBR) minutes of housekeeping telemetry data is preserved. Capability to preserve more than 10 (TBR) minutes of housekeeping telemetry data is acceptable.

LSim-287 The LOpS shall generate an uncompressed imaging sensor data rate less than

1.8 (TBR) Gbps.

Rationale: To reduce the data bandwidth from the instrument to the data handling function.

Note: Preprocessing to perform co-addition, spatial aggregation, dynamic range adjustment and final windowing or selection of significant bits is allowed and expected.

LSim-288 The LOpS shall be ready to generate imaging sensor data within 5 (TBR) seconds of receipt of command to capture imaging sensor data.

Rationale: To ensure the simulator isready to generate data in a timely manner like the flight unit, when commanded.

LSim-289 The LOpS collection duration time period for imaging sensor data block shall be configurable, upon command.

Rationale: Allows adjustability to the time duration for the imaging sensor data block for optimization of compression.

3.1.2.1 Ancillary Data

LSim-238 The LOpS shall package compressed imaging sensor data and uncompressed instrument ancillary data into instrument data blocks.

Rationale: Instrument data blocks include all LOpS generated data necessary for Mission Data File generation.

LSim-239 The LOpS shall produce uncompressed instrument ancillary data.

Rationale: The LOpS needs to produce ancillary data to support mission data processing.

LSim-277 The instrument ancillary data stored with each instrument data block shall be time-correlated with the full image exposure plus (TBD) margin before and after the image.

Rationale: To support Mission Data File processing on the ground. Additional instrument ancillary data is desired prior to the start of image exposure and after completion of the image capture to account for internal timing differences. It is understood that some instrument ancillary data will be captured and transmitted twice (within two separate instrument data blocks).

3.1.2.2 Imaging Sensor Data

LSim-9 The LOpS when configured shall compress imaging sensor data per CCSDS

123.0-B-2 specification.

Rationale: Compression will be per Low-Complexity Lossless and Near-lossless Multispectral and Hyperspectral Image Compression specification. The compression algorithm (CCSDS 123) needs to conform to the standard per Annex A of the specification.

LSim-241 The LOpS shall be configurable (commandable) to either compress or not compress imaging sensor data.

Rationale: This allows confirmation and/or diagnosis of the compression algorithm.

Note: The CCSDS 123 Header will serve as the key frame.

LSim-242 The LOpS Compression shall utilize configurable (commandable) compression such that alternate compression configurations can be used per band, per collect type.

Rationale: With configurable compression, the entropy in each band results in a different amount of compression, with the following capabilities:

• Enable/disable compression

• Configure the maximum absolute sample error per band and per interval (i.e. calibration intervals will be set to lossless, while Earth imaging will be lossy for certain bands)

• Certain bands may be sent to lossless compression, e.g., atmospheric bands

LSim-244 The LOpS shall provide the same data reduction, compression, and non-uniformity correction capability as the flight instruments.

Rationale: The LOpS will need to provide the same capabilities that the flight instruments does in the LandIS Requirements Document (LaRD) (LNEXT-LANDIS-REQ-0007), section 10.2 in order to match flight unit imaging sensor data output.

LSim-41 The LOpS shall ingest uncompressed imaging sensor data from a file prior to compression.

Rationale: To verify data timing integrity during ground testing from uncompressed data through compression onward.

LSim-278 The LOpS shall ingest files that contain up to 36 minutes of continuous daylight imaging

Rationale: The LoPS must match the flight unit's capability to image for the longest possible daylight contiguous land pass

LSim-42 The LOpS shall generate and transmit continuous simulated imaging sensor data with different image patterns.

Rationale: This should include generating/producing nominal image test patterns and diagnostic imaging sensor data as is appropriate. The LOpS requires continuous simulated, proxy imaging sensor data.

LSim-44 The LOpS shall generate and send LandIS imaging sensor data streams with representative data across the output data bus in all valid formats and data rates.

Rationale: The data going across the output data bus on the LOpS will need to match the flight unit as defined in LandIS Interface Requirement Document (LIRD) (LNEXT-LANDIS-ICD- 0001), Section 3.2.5.1.

LSim-271 The LOpS shall generate and send LandIS ancillary data streams with representative data across the output data bus in all valid formats and data rates.

0001),Section 3.2.5.1

3.1.2.3 Telemetry

LSim-31 The LOpS shall generate and transmit real-time instrument housekeeping data to the LNext spacecraft in all valid formats and data rates as specified in the LandIS Interface Requirement Document (LIRD) (LNEXT-LANDIS-

ICD-0001).

0001).

LSim-3 The LOpS shall generate real-time instrument housekeeping data.

Rationale: This capability mirrors the functionality of the flight instrument. Real-time housekeeping data is needed to monitor and control the instrument including power on status of all prime and redundant components as well as instrument configuration/mode.

LSim-7 The LOpS shall produce housekeeping data whenever powered.

Rationale: This is the basic requirement for telemetry in any instrument powered configuration where operational power is applied.

LSim-26 The LOpS shall simulate the Instrument flight-like response in telemetry after receipt of command.

Rationale: The LOpS should simulate the telemetry responses to commands in the same manner the flight unit would in flight.

LSim-275 The LOpS shall provide bi-level or analog Telemetry to indicate execution of individual discrete commands.

Rationale: Discrete commands are typically used to configure electronics without the availability of serial telemetry (e.g. while the unit is powered off).

3.1.2.4 Command Capability

LSim-16 The LOpS shall provide responses to bi-level (both states) and discrete commands consistent with the LandIS Interface Requirement Document

(LIRD) (LNEXT-LANDIS-ICD-0001).

LSim-145 The LOpS shall only execute commands that have been validated.

Rationale: Executing unvalidated commands will have an unpredictable response.

LSim-247 The LOpS shall report commands that have failed validation in housekeeping telemetry and event log.

Rationale: To make operations aware that a command did not pass validation, so they can take appropriate actions.

LSim-22 The LOpS shall execute commands at a minimum frequency of 10 commands per second.

Rationale: The LOpS will need to replicate the flight instrument to ensure timely execution of command loads.

LSim-248 Upon receipt of a valid command the LOpS shall start execution of the command within 100 milliseconds.

Rationale: Commands are to be executed with minimum delay by LOpS.

LSim-30 The LOpS shall upon receipt of a command, validate, process and execute commands in real-time.

Rationale: External commands to LOpS are to be validated, processed and executed in real-time without delay.

3.1.3 Input and Output Data Buses

LSim-15 The LOpS shall provide a flight-like output data bus interface for imaging sensor data, ancillary data, and telemetry consistent with the LandIS Interface Requirement Document (LIRD) (LNEXT-LANDIS-ICD-0001).

Rationale: To provide testing of the input or output data bus interface characteristics validate data exchanged between the LandIS Simulator and SC or SOpS.

LSim-249 The LOpS shall provide a flight-like input data bus interface for commands and time-of-day time code consistent with the LandIS Interface Requirement Document (LIRD) (LNEXT-LANDIS-ICD-0001).

Rationale: To validate data exchanged between the LOpS and SC or SOpS, the LOpS will need to provide an input data bus as defined in the LandIS Interface Requirement Document (LIRD)

(LNEXT-LANDIS-ICD-0001).

LSim-23 The LOpS Simulator shall provide data flow over the output data bus consistent with the LandIS Interface Requirement Document (LIRD)

(LNEXT-LANDIS-ICD-0001).

Rationale: To provide testing of the of the LOpS output data bus interface characteristics between Spacecraft and instrument for format and size.

LSim-45 The LOpS shall have the capability to enable or disable the capture of all data exchanged between the LOpS and SOpS or spacecraft and store for offline analysis.

Rationale: It is necessary to capture data that is exchanged between instrument and spacecraft simulators for analysis.

3.1.4 FSW & DB

LSim-24 The LOpS shall operate using the LandIS flight software, databases, and limits.

Rationale: The operations Database (DB) and Flight Software (FSW) should be used on the simulator to allow for validation of activities performed on the simulator.

LSim-28 LOpS flight software shall receive updates, as patches, at the function, unit, or module level.

Rationale: The LOpS simulator will have the same capability as the flight unit for supporting on-orbit software updates for errors and enhancements.

LSim-29 LOpS shall run unmodified flight code for all updatable code.

Rationale: Software functionality must mirror the flight unit and allow Flight Operations to operate the LOpS FSW in the same manner as the flight unit.

LSim-32 The LOpS generated imaging sensor data shall be in the same format as flight instrument as specified in the LandIS Interface Requirement Document

Rationale: Imaging sensor data generated from a file or the onboard test pattern will be provided to the spacecraft in the same format as defined in the LandIS Interface Requirement Document

(LIRD) (LNEXT-LANDIS-ICD-0001).

LSim-33 The LOpS shall be delivered with all of the FSW operational capabilities of the flight instrument.

Rationale: The LOpS must be delivered with the same FSW management capabilities defined in LandIS Requirements Document (LaRD) (LNEXT-LANDIS-REQ-0007), section 9 as the flight unit for the verification and validation of operation products and process.

LSim-8 LOpS shall provide and simulate the same onboard subsystem self-diagnostics and reporting as the flight instrument.

LSim-250 The LOpS subsystems that performs self-diagnostics shall report the results in housekeeping telemetry or a diagnostic stream.

Rationale: Diagnostic data that can be reported in housekeeping telemetry should be reported; a large amount of diagnostic data may require a special downlink packet(s) (e.g. Application Process Identifier (APID))

LSim-251 The LOpS subsystems that support self-diagnostics shall accept commands to run self-diagnostics and report the results in telemetry as an event.

Rationale: When commanded, LOpS subsystems with diagnostics capabilities will report their results in telemetry in the same way the flight instrument will.

LSim-252 The LOpS shall log all events that the flight instrument does.

Rationale: The LOpS will need to mirror the flight instrument capability from LandIS Requirements Document (LaRD) (LNEXT-LANDIS-REQ-0007), section 9.3.

3.1.5 Failure Response and Redundancy

LSim-48 The LOpS shall simulate the response of all autonomous configuration changes from a simulated component or subsystem failure.

Rationale: The LOpS will need to accurately simulate the responses and characteristics of autonomous configuration changes caused by simulated faults.

LSim-49 The LOpS shall replicate flight subsystem instrument failover response.

Rationale: LOpS response should reflect what the flight system configuration would be in the event of the failover in telemetry.

LSim-52 The LOpS shall emulate the internal flight hardware response for any internal redundancy.

Rationale: LOpS must accept commands and provide realistic response to transition to redundant systems.

LSim-54 The LOpS shall override autonomous functions, automatic safing or switchover via command.

Rationale: This permits diagnosis of failures and anomalies within the instrument via command.

LSim-55 The LOpS shall report autonomous state changes and reconfigurations in housekeeping telemetry.

Rationale: LOpS telemetry needs to report state changes for detection of failures and anomalies within the instrument simulator.

LSim-58 The LOpS shall simulate Instrument response to transition to safe configurations.

Rationale: The LOpS will provide flight-like response.

LSim-253 The LOpS shall report on simulated fault conditions identical to the flight fault reporting.

Rationale: LOpS will need to replicate the flight unit reporting of out-of-limit and fault conditions in housekeeping telemetry. This will allow for ground observation and autonomous responses by the SOpS or spacecraft.

3.1.6 Electrical Systems

LSim-37 The LOpS shall utilize flight quality connectors and flight quality pins that match the flight instrument as defined in Spacecraft to LandIS ICD.

Rationale: The LOpS will mate to the Spacecraft to test the electrical interface and will need a flight compatible connector.

LSim-141 LOpS circuits interfacing directly to flight hardware shall be powered via a separate, dedicated source from other simulator electronics.

LSim-142 LOpS shall contain an electrical self-test and instrument functional validation checkout using standard 110 VAC power.

LSim-272 The LOpS Simulator shall simulate nominal instrument current draw for each Main Bus Operational power service and Main Bus Survival Heater Power Service.

3.1.7 Grounding

LSim-47 The LOpS Simulator shall implement a grounding scheme representative of the Flight Instrument grounding, preserving the satellite grounding scheme.

Rationale: The Instrument Simulator will mate to the Spacecraft to test the electrical interface.

3.1.8 Simulator Operations

LSim-25 The LOpS shall simulate Instrument response to the operational constraints.

Rationale: The LOpS models should enforce operational constraint to validate that the instrument operates as the flight instrument does.

LSim-61 The LOpS shall respond to real-time operator changes in the configuration of the simulated LandIS.

LSim-139 The LOpS shall be designed to operate in a cleanroom environment at the instrument and spacecraft facilities.

Rationale: The LOpS will be designed in a manner, in which they can be placed in the cleanroom for use during Integration and Test (I&T) risk reduction.

LSim-39 The LOpS shall operate both mated to and independent from the SOpS or

Spacecraft.

Rationale: In support of diagnostics of the flight instrument, it may be necessary to run the LOpS “off-line” from the flight spacecraft or the SOpS. This functionality may also be useful for developing response characteristics in the LOpS.

LSim-149 LOpS shall allow the users to perform test in a "Test as you Fly" manner in which, once the Simulator is configured it can be operated without intervention for 120 hours (TBD).

Rationale: The LOpS needs to allow users to test uninterrupted for the duration of planned activities without operator intervention. The 120 hours (TBD) represents the expected duration of the long duration testing on the LOpS.

LSim-229 The LOpS shall be capable of being reset from an operational state to powered off and back into an operational state within 15 minutes.

Rationale: To support testing the LOpS will be capable of being reset and ready for operations within 15 minutes.

LSim-230 The LOpS shall maintain resource reserves for CPU, Storage, Memory, Network bandwidth of ≥25% and provide a way to monitor for those.

3.1.9 Operations Interface

LSim-62 The LOpS shall accept inputs from the user to set and change simulation variables in housekeeping TLM and/or imaging sensor data.

LSim-63 The LOpS shall accept inputs from the user to set and synchronize simulation time with the Observatory clock time and the ground system time.

LSim-65 Upon command, the LOpS while not integrated to the Spacecraft or SOpS shall run previously executed simulations.

Rationale: This allows testing and trainers to establish a baseline set of training simulations and to be able reproduce a simulation when not connected to the SOpS.

LSim-21 LOpS shall have the ability to override all model generated Telemetry

(TLM) point values within the ranges defined in the LandIS Command and Telemetry (C&T) Handbook.

Rationale: Ranges for all values will be defined in the LandIS C&T DB, and the ability to manipulate the TLM mnemonics to valid values is a critical capability to support product development, Mission Simulations, and Mission Readiness Test (MRT) development.

LSim-146 LOpS shall provide the user a Graphical User Interface for Simulator

Operations.

Rationale: This allows users to easily manipulate and operate the LOpS both during startup and during operations.

LSim-147 LOpS shall provide the user with the capability to configure the Simulator via script.

Rationale: This allows the user the ability to generate specific configurations during mission readiness testing and anomaly resolution.

LSim-280 LOpS shall allow image sensor data files to be ingested based on SC provided TOD(Time of Day) message.

Rationale: The LOpS will need the capability to start ingesting files based on SC TOD messages so that the scenes being ingested can be sync’d with the desired SC time and location

LSim-281 The LOpS Shall allow the user to generate a queue of files up to the number of intervals in the DRC-18(LSDS-2389) to be played back by TOD

Rationale: To support long duration testing the LOpS will need the capability to queue multiple files that will be played back based on TOD

LSim-282 The LOpS image sensor data file storage shall be sized to support the raw uncompressed data files to execute the Design Reference Case(DRC) in

DRC-18(LSDS-2389).

Rationale: The LOpS will need the capability to have the full image sensor files stored onboard for the 18 day DRC.

LSim-148 The LOpS shall have capability for secure and remote external user access to support control and maintenance over the life of the Mission.

Rationale: This capability will allow the LOpS contractor, government employees, and government contractors the ability to continue working while remote from the LOpS. This should include but is not limited to access and control of the LOpS desktop for remote management activities such as viewing files, changing files, fixing technical issues, and changing configuration settings.

LSim-150 The LOpS shall have the capability to save the current configuration and state of the simulation to be re-loaded at a later time.

Rationale: The LOpS will have the ability to create and load configurations and scenarios for use in ground and mission readiness testing.

LSim-151 The LOpS shall have the capability to pause a simulation in its current state and allow the user to resume without any loss of the previous configuration.

Rationale: The LOpS will have the ability to pause the current simulation for use in ground and mission readiness testing.

LSim-226 The LOpS shall maintain log files that capture all received commands, directives, and faults to support monitoring, support and debugging of simulator.

Rationale: The LOpS need the capability to log pertinent information to allow for monitoring, support and debugging of the simulator.

LSim-227 The LOpS log files shall be captured in a separate log file from LOpS event messages generated during simulator operations.

Rationale: The LOpS will keep information used for monitoring, support, and debugging separately from the logs generated by the LOpS during operations.

LSim-228 The LOpS logs shall be captured for the duration that simulator power is applied to the machine.

Rationale: All events during LOpS powered time will be captured.

3.1.10 Thermal

LSim-43 The LOpS Simulator shall simulate flight-like survival and operational heater temperature and sensor data.

Rationale: Allows the LOpS to test with realistic thermal conditions and respond to operational constraints.

LSim-68 LOpS shall simulate a thermal model which has flight like responses.

Rationale: Allows LOpS to test with realistic thermal functions and responses.

LSim-57 The LOpS shall simulate flight-like survival heater and operational heater current draw, using resistive loads, per each of the Main Bus Survival Heater power services and Main Bus Operational power services defined in Spacecraft to Instrument ICD.

4.0 LANDIS INTERFACE SIMULATOR (LIS)

4.1 GENERAL

4.1.1 Mission Modes & States

LSim-183 The LIS shall initialize to the same basic power on state that the flight instrument does upon application of operational power.

Rationale: This capability mirrors the functionality of the flight instrument. Need a basic engineering state to power on into and proceed to configure the instrument into its nominal science configuration.

4.1.2 Command and Data Handling (C&DH)

LSim-188 The LIS shall include a watchdog timer which is to reset the microprocessor after a specified interval of time, unless the timer is restarted.

Rationale: The operational flight software will periodically “pet” or restart the watchdog timer.

After being restarted, the watchdog will begin timing for another predetermined interval. The flight software may also force a processor restart by allowing the watchdog timer to expire.

LSim-191 The LIS shall replicate flight design and use flight like parts to the first active circuit level, for all digital and analog signals that interface to the spacecraft bus.

Rationale: LIS may need to connect to the Spacecraft and should use flight-like parts as stated in the requirement.

LSim-258 The LIS Simulator shall replicate Instrument internal timing with respect to the time-of-day time code message and time-of-day signal, as defined in LandIS Interface Requirement Document (LIRD) (LNEXT-LANDIS-ICD- 0001).

Rationale: The LIS will be integrated with the flight SC and will need to have timing that matches the LandIS flight unit to identify any potential issues with the interface

LSim-290 The LIS shall generate an uncompressed imaging sensor data rate less than

1.8 (TBR) Gbps.

Rationale: To reduce the data bandwidth from the instrument to the data handling function.

Note: Preprocessing to perform co-addition, spatial aggregation, dynamic range adjustment and final windowing or selection of significant bits is allowed and expected.

LSim-291 The LIS shall be ready to generate imaging sensor data within 5 (TBR) seconds of receipt of command to capture imaging sensor data.

Rationale: To ensure the simulator isready to generate data in a timely manner like the flight unit, when commanded.

LSim-292 The LIS collection duration time period for imaging sensor data block shall be configurable, upon command.

Rationale: Allows adjustability to the time duration for the imaging sensor data block for optimization of compression.

4.1.2.1 Ancillary Data

LSim-259 The LIS shall produce uncompressed instrument ancillary data.

Rationale: The LIS needs to produce ancillary data to support mission data processing

LSim-260 The LIS shall package compressed imaging sensor data and uncompressed instrument ancillary data into instrument data blocks.

Rationale: Instrument data blocks include all LIS generated data necessary for Mission Data File generation.

4.1.2.2 Imaging Sensor Data

LSim-223 The LIS shall ingest uncompressed imaging sensor data from a file.

Rationale: To verify data timing integrity during ground testing from uncompressed data through compression onward.

LSim-283 The LIS shall ingest files that that contain up to 36 minutes of continuous daylight imaging

Rationale: The LIS must match the flight unit's capability to image for the longest possible daylight contiguous land pass

LSim-225 The LIS shall generate and transmit continuous simulated imaging sensor data with different image patterns.

Rationale: This should include generating/producing nominal image test patterns and diagnostic imaging sensor data as is appropriate.

LSim-224 The LIS shall ingest compressed imaging sensor data from a file.

4.1.2.3 Telemetry

LSim-198 The LIS shall generate and transmit real-time instrument housekeeping data in all valid formats and data rates as specified in the LandIS Interface Requirement Document (LIRD) (LNEXT-LANDIS-ICD-0001).

Rationale: The data going across the output data bus on the LIS will need to match the flight

0001), Section 3.2.5.1

LSim-196 The LIS shall simulate the Instrument flight-like response in telemetry after receipt of command.

Rationale: The LIS should replicate state of health data structure in response.

4.1.2.4 Command Capability

LSim-187 The LIS shall provide responses to bi-level (both states) and discrete commands consistent with the LandIS Interface Requirement Document

LSim-190 The LIS shall only execute commands that have been validated.

Rationale: Executing unvalidated commands will have an unpredictable response.

LSim-261 The LIS shall report commands that have failed validation in housekeeping telemetry and event log.

Rationale: To make operations aware that a command did not pass validation, so they can take appropriate actions.

LSim-192 The LIS shall execute commands at a minimum frequency of 10 commands per second.

Rationale: The LIS will need to replicate the flight instrument to ensure timely execution of command loads.

LSim-262 Commands are to be executed with minimum delay by LandIS.

Rationale: Commands are to be executed with minimum delay by LIS.

LSim-197 The LIS shall upon receipt of a command validate, process and execute commands in real-time.

Rationale: External commands to LIS are to be validated, processed and executed in real-time without delay.

4.1.3 Input and Output Data Buses

LSim-186 The LIS shall provide a flight-like output data bus interface for imaging sensor data, ancillary data, and telemetry consistent with the LandIS Interface Requirement Document (LIRD) (LNEXT-LANDIS-ICD-0001).

Rationale: To provide testing of the output data bus interface characteristics between the LIS and SC.

LSim-263 The LIS shall provide a flight-like input data bus interface for commands

Rationale: To provide testing of the input data bus interface characteristics between the LIS and

SC.

LSim-194 The LIS Simulator shall provide data flow over the output data bus

Rationale: To provide testing of the of the LIS output data bus interface characteristics between Spacecraft and instrument for format and size.

4.1.4 FSW & DB

LSim-199 The LIS generated imaging sensor data shall be in the same format as flight instrument as specified in LandIS Interface Requirement Document (LIRD)

Rationale: Imaging sensor data generated from a file or the onboard test pattern will be provided to the spacecraft in the same format as defined in the LandIS Interface Requirement Document

LSim-264 The LIS shall operate using the LandIS flight software, databases, and limits.

Rationale: The operations Database (DB) and Flight Software (FSW) should be used on the simulator to allow for validation of activities performed on the simulator.

LSim-200 The LIS shall be delivered with all of the FSW operational capabilities of the flight instrument.

Rationale: The LIS must be delivered with the same FSW management capabilities defined in LandIS Requirements Document (LaRD) (LNEXT-LANDIS-REQ-0007), section 9 as the flight unit for the verification and validation of operation products and process.

4.1.5 Electrical Systems

LSim-14 The LIS Simulator shall simulate nominal instrument current draw for each

Main Bus Operational power service and Main Bus Survival Heater Power Service.

LSim-202 The LIS shall utilize flight quality connectors and flight quality pins that match the flight instrument as defined in Spacecraft to LandIS ICD.

Rationale: The LIS will mate to the Spacecraft to test the electrical interface and will need a flight compatible connector.

LSim-40 The LIS Simulator simulated power loads shall be individually controllable

(on/off) by command through the simulator user interface.

LSim-204 LIS circuits interfacing directly to flight hardware shall be powered via a separate, dedicated source from other simulator electronics.

LSim-205 LIS shall contain an electrical self-test and instrument functional validation checkout using standard 110 VAC power.

4.1.6 Grounding

LSim-207 The LIS shall implement a…