Attachment C - L10 Spacecraft Requirements Document (SC SRD).pdf
PDF 1 MB Posted
- Attached to
- Landsat 10 Spacecraft _ DRAFT RFP
- Solicitation number
- 80GSFC26D0015
About this file
This is the Landsat 10 Spacecraft Requirements Document (SRD), a Level 3 requirements specification for the Landsat 10 spacecraft being developed by NASA's Goddard Space Flight Center under RFP 80GSFC26R0015. The document establishes comprehensive functional and performance requirements for a single-spacecraft observatory mission designed to continue the Landsat program's acquisition and distribution of multispectral Earth imagery. The spacecraft will operate in a 653 km sun-synchronous orbit with an 18-day repeat cycle, carrying the Landsat Instrument Suite (LandIS) to provide global coverage of Earth's land surfaces and coastal regions with improved spectral and spatial capabilities compared to previous Landsat missions. The mission design life is 5.25 years, with a maximum launch mass of 4,000 kilograms, and the spacecraft must achieve controlled re-entry at mission end with specific debris casualty area limitations.
The SRD specifies detailed requirements across all spacecraft subsystems including power (battery with 20% lifetime margin, multi-level load shedding), thermal management (autonomous operation post-initialization), propulsion (capability for precise orbit adjustments down to 0.25 cm/sec), attitude and orbit control (with specific pointing accuracy and stability margin requirements), communications (S-band narrowband and Ka-band wideband capability), flight software (deterministic real-time processing with autonomous fault management), command and data handling (8+ Terabits mass storage capacity with mission data file management), and spacecraft operational autonomy (automated planning of imaging, communications, and ground-directed activities). Additionally, the document establishes requirements for redundancy and single-fault tolerance across critical systems, data loss limitations (0.15% over mission life), ancillary data collection with specific timing accuracy, and extensive telemetry monitoring and housekeeping data collection. The spacecraft must also support continuous imaging operations, off-nadir imaging up to 15 degrees cross-track, and maintain compatibility with launch vehicle interfaces including propellant loading in vertical orientation and final closeout prior to fairing encapsulation.
View the file
Other files
Show all 46
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Attachment No. C
Landsat 10 Spacecraft Requirements Document
(SC SRD)
RFP 80GSFC26R0015
National Aeronautics and Space Administration Goddard Space Flight Center
Landsat 10 SRD L10-SC-REQ-0011 Revision C ii Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
Landsat 10 Spacecraft Requirements Document (SRD) Signature/Approval Page
Prepared by:
Electronic Signature in TDMS Approval Date in TDMS James Hritzo Date Landsat 10 Spacecraft Systems Engineer NASA/GSFC, Code 590
Approved by:
Cagatay Aymergen Date Landsat 10 Deputy Project Manager / Acting Observatory Manager
NASA/GSFC, Code 426
Ross Henry Date Landsat 10 Project Manager NASA/GSFC, Code 426
Evan Webb Date Landsat 10 Mission Systems Manager NASA/GSFC, Code 533 iii Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
CM Foreword This document is a Landsat 10 Project Configuration Management (CM)-controlled document.
Note: Prior to February 2026, the project name was Landsat Next (LNext).
For the purposes of configuration management, the prefixes “LNEXT” and “L10” are completely interchangeable. For example, LNEXT-MGMT-PLAN-0004 is the same as L10-MGMT-PLAN- 0004.
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 10 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 10 Project Office, Code 426 Attention: Configuration Management Office Greenbelt, Maryland 20771 iv Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
Change History Log v Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
Table of Contents SIGNATURE/APPROVAL PAGE ................................................................................................ II
CM FOREWORD ..........................................................................................................................III
CHANGE HISTORY LOG .......................................................................................................... IV
TABLE OF CONTENTS ................................................................................................................ V
LIST OF FIGURES .................................................................................................................... VIII
LIST OF TABLES ...................................................................................................................... VIII
1.0 INTRODUCTION
1.1 Purpose
1.2 Scope
1.3 Related Documentation
1.3.1 Applicable Documents
1.3.2 Reference Documents
1.3.3 Project Reference 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 DESIGN LIFE
3.1 Mission Phases
3.1.1 Pre-Launch Phase
3.1.2 Launch and Early Orbit Phase
3.1.3 Spacecraft Decommissioning Phase
3.2 Orbits
3.2.1 Injection Orbit
3.2.2 Operational Orbit
3.2.3 Disposal Orbit
3.3 Imaging Support
3.4 Spacecraft Operations
3.4.1 Spacecraft Modes
3.4.2 Operational Contingency Response
3.5 Redundancy and Single-Fault Tolerance Design Requirements
3.6 Fault Management
3.6.1 Telemetry Monitoring
3.7 Availability
3.8 Data Loss
3.9 Structural and Mechanical Systems
vi Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
3.9.1 Mechanisms and Deployable Design Requirements
3.10 Thermal System
3.11 Electrical System
3.11.1 Energy Collection and Storage
3.11.2 Power Distribution and Monitoring
3.11.2.1 Power Distribution for Hazardous Functions
3.11.2.2 Power Fault Protection
3.11.3 Grounding
3.11.3.1 Power and Signal Returns
3.11.3.2 Class R Grounding
3.11.3.3 Electrostatic (Class S) Grounding
3.11.4 Flight Plugs
3.11.5 Harness and Connector Design
3.11.5.1 Signal and Power Routing
3.11.5.2 External Interfaces
3.11.6 Solar Array
3.12 Flight Software
3.12.1 Startup Read Only Memory (SUROM)
3.12.2 Deterministic Processing
3.12.3 Memory Operations
3.12.4 Memory Margin
3.12.5 Flight Software Patch Upload
3.12.6 Version Identifiers
3.12.7 Event Logging
3.12.8 Initialization
3.12.9 Commands
3.12.10 Stored Commands
3.12.11 State-of-Health (SOH) Telemetry
3.12.11.1 General
3.12.11.2 Telemetry Content
3.12.11.3 Configurability
3.12.11.4 SOH Storage
3.12.11.5 SOH Playback
3.12.12 Ancillary Data
3.13 Firmware
3.13.1 Version Identifiers
3.14 Command and Data Handling System
3.14.1 General
3.14.2 Commands
3.14.3 Mass Storage
3.14.3.1 General
3.14.3.2 Mission Data Files (MDFs)
3.14.3.3 Volume Table of Contents (VTOC)
3.14.3.4 Erase and Record Operations
3.14.3.5 Playback Operations
3.14.3.6 Mass Storage Data Integrity
vii Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
3.14.3.7 Diagnostic and Test
3.15 Spacecraft Operational Autonomy
3.15.1 Activities
3.15.1.1 Activity Definition
3.15.2 Communications Activity Schedule (CAS)
3.15.2.1 Communications Activity Schedule Inputs
3.15.2.2 Communications Activity Schedule (CAS) Generation
3.15.2.3 Communications Activity Schedule Outputs
3.15.3 Imaging Plan
3.15.3.1 Long Term Acquisition Plan (LTAP) Collection Request (LCR) ..50
3.15.3.2 Special Collection Request (SCR)
3.15.3.3 Imaging Plan Generation
3.15.3.4 Imaging Plan Outputs
3.15.4 Ground-Directed Activity Timeline (GDAL)
3.15.4.1 GDAL Inputs
3.15.4.2 GDAL Generation
3.15.4.3 GDAL Outputs
3.15.5 Integrated Onboard Timeline (IOT)
3.15.5.1 IOT Generation
3.15.5.2 IOT Outputs
3.16 Attitude and Orbit Control
3.16.1 Maneuvers
3.16.1.1 Orbit Maneuvers
3.16.1.2 Attitude Maneuvers
3.16.2 Ephemeris
3.16.3 Spacecraft State Knowledge
3.16.4 Spacecraft Attitude Knowledge
3.16.5 Spacecraft Attitude Control
3.16.6 Stability Margins
3.17 Propulsion System
3.18 Radio Frequency Telecommunications System
3.18.1 General
3.18.2 Narrowband (S-Band)
3.18.3 Wideband (Ka-Band)
3.18.4 Multipaction and Corona Avoidance
3.18.5 Directed Venting
3.18.6 Ground Storage
APPENDIX A OBSERVATORY TO LAUNCH VEHICLE INTERFACE DESIGN
REQUIREMENTS
A.1 Mechanical Interfaces A.2 Final Closeouts Prior to Encapsulation A.3 Propellant Loading and Contingency Offloading A.4 Ground Interfaces
APPENDIX B ABBREVIATIONS AND ACRONYMS
APPENDIX C DEFINITIONS
viii Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
List of Figures Figure 2.4-1 Landsat 10 Mission Architecture
List of Tables Table 2.4.1-1 Landsat 10 Mission Parameters Table 3.2.1-1 Landsat 10 Injection Orbit Table 3.2.2-1 Landsat 10 Operational Orbit
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
1.0 INTRODUCTION
1.1 PURPOSE
The Landsat 10 Spacecraft Requirements Document (SRD) defines the requirements for the Landsat 10 Spacecraft.
1.2 SCOPE
The Landsat 10 Spacecraft Requirements Document (SRD) establishes a set of Level 3 requirements for the Landsat 10 Spacecraft in support of the Landsat 10 Project. As a Level 3 document, it contains functional and performance requirements.
The requirements in main body of the SRD provide requirements to be levied on each individual spacecraft such that each spacecraft must meet requirements as a standalone unit. The requirements in Appendix A outline functional and performance launch vehicle interface requirements applicable to the Observatory.
The following definitions apply to the action verbs used in this requirements document:
• Shall: Directive – Compliance by the Contractor is mandatory. Any deviations from these contractually imposed mandatory requirements require the approval of the contracting officer.
• May: Permissive – Allows an option for compliance at the discretion of the Contractor or Government.
• Will: Informative – Designates the intent of the Government. Unless required by other contract provisions, noncompliance with the will requirements does not require approval of the contracting officer and does not require documented technical substantiation.
• Should: Advisory – Gives guidance to the Contractor for the performance of this contract.
• Must: Advisory – Notifies the Contractor of important relevant conditions that may be outside the context of this contract.
1.3 RELATED DOCUMENTATION
1.3.1 Applicable Documents
Document Number Title Revision Section Reference
NASA-STD-4003 Electrical Bonding for NASA Launch Vehicles, Spacecraft, Payloads, and Flight Equipment
A w/CHANGE 1 All
NASA-STD-5017 Design and Development Requirements for Mechanisms
B All
NASA-STD-8719.14 Process for Limiting Orbital Debris C All NPR 8715.6 NASA Procedural Requirements for
Orbital Debris Mitigation E All
In this document, citations are assumed to be the latest version unless otherwise noted.
This document table was generated from the Landsat 10 Common Reference and Applicable Documents List (L10-MGMT-DESC-0008), DRAFT Rev F.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
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.
1.3.3 Project Reference Documents
Document Number Title L10-SC-ICD-0002 Landsat 10 Spacecraft Interface Requirements Document
(SCIRD)
L10-SC-ICD-0004 Landsat 10 Spacecraft to Ground Interface Control Document
(SC-GND ICD)
L10-SC-ICD-0007 Landsat 10 Spacecraft to Ground Interface Requirements
Document (SC-GND IRD) L10-SC-REQ-0029 Landsat 10 Spacecraft Contract Data Requirements List
(CDRL) and Data Item Descriptions (DID) L10-SYS-DESC-0007 Landsat 10 Geometric Error Budget (GEB) Support
Presentation L10-SYS-DESC-0016 Landsat 10 Geometric Error Budget (GEB) L10-SYS-DESC-0018 Landsat 10 World Reference System-3 (WRS-3) L10-SYS-PLAN-0027 Landsat 10 Project Protection Plan (PPP) L10-SYS-TN-0001 Debris Casualty Area (DCA) Suballocation for Landsat 10 LSDS-2389 Landsat 10 Design Reference Case – 18 Days (DRC-18)
Definition In this document, citations are assumed to be the latest version unless otherwise noted.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
2.0 MISSION OVERVIEW
2.1 MISSION STATEMENT
Landsat 10, consistent with United States (U.S.) law and government policy, will continue the Landsat program's acquisition, archival, and distribution of multi-spectral imagery, thereby affording global, synoptic, and repetitive coverage of the Earth's land surfaces and coastal regions 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 the National Aeronautics and Space Administration (NASA) recognized the need to assemble a team of experts from within both agencies to evaluate and 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 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 July 2018, Release
2.0. This investigation 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 surfaces and coastal regions held in the National Satellite Land Remote Sensing Data Archive at the 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. Landsat Next subsequently passed its Mission Concept Review (MCR) and Key Decision Point-A (KDP-A) reviews in 2022. In March 2026, the Landsat Next mission was re-architected and re-designated Landsat 10 as a single observatory mission.
The goal of Landsat 10 is to continue the acquisition, archival, and distribution of multi-spectral imagery, thereby affording global, synoptic, and repetitive coverage of the Earth's land surfaces and coastal regions 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 10 continues the long-running partnership of NASA and the USGS, with NASA providing the space and launch segments and the USGS providing the ground system (GS), providing the longest continuous global record of the Earth’s land surface and coastal regions.
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.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
2.3 MISSION OBJECTIVES
Landsat 10 has these major mission objectives:
· Collect and archive moderate resolution Visible to Shortwave-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 10 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; all of which permit scientific studies, management of land cover and land use change, along with associated inland and coastal water resources, over multi-decadal periods.
· Ensure Landsat 10 is responsive to documented emerging user needs and applications as characterized by periodic assessment, currently the User Needs for the SLI Program July 2018, Release 2.0, and identified by the operational requirements for acquisition, processing, archiving, and distribution of Earth’s image data to the United States Government and other users.
· Distribute Landsat 10 data products to the public freely on a nondiscriminatory basis.
2.4 MISSION IMPLEMENTATION
The Landsat 10 mission includes a single observatory in a 653 km sun-synchronous low-earth orbit (LEO). The observatory includes a single integrated suite of sensors called LandIS (the Landsat Instrument Suite) that images the full swath required to achieve global coverage via a repeating ground track every 18 days.
The LandIS improves all spectral and spatial capabilities by approximately twofold when compared with the Operational Land Imager (OLI) and Thermal InfraRed Sensor (TIRS) instruments flown on Landsats 8 and 9, while maintaining the historical Landsat data continuity and similar temporal coverage.
Each Landsat 10 partner agency has specific responsibilities and will deliver major elements to the overall mission. NASA will provide the Space Segment (SS) and the Launch Services Segment (LSS), and the USGS will provide the Ground System (GS) and Mission Operations.
NASA/Goddard Space Flight Center (GSFC) will provide overall Landsat 10 project management, mission system engineering and mission assurance during development and will transition the mission to USGS for science operations following on-orbit commissioning.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
Figure 2.4-1 Landsat 10 Mission Architecture
(Generated from Landsat 10 Common Mission Architecture Diagram L10-SYS-DESC-0022 Rev B)
2.4.1 Space Segment
NASA/GSFC provides the Space Segment via competitive procurements for the science instrument suite (LandIS) and the spacecraft bus. The Space Segment will consist of a single observatory flying in a sun-synchronous, near-polar orbit at 653 km altitude. The spacecraft, instrument, and overall Landsat 10 mission are specified as risk class C per NPR 8705.4. The overall mission parameters needed to achieve global coverage are shown below in the Mission Parameters Table.
Table 2.4.1-1 Landsat 10 Mission Parameters
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
LandIS is a whiskbroom scanner which provides 26 spectral bands covering a swath on the ground of approximately 164 km on a fixed ground track defined by a world-wide reference system known as WRS-3. LandIS acquires raw detector data for all spectral bands within 15 seconds to minimize band-to-band and georegistration errors, reduce classification change detection errors due to clouds, and provide simultaneous acquisitions for science applications.
LandIS then performs data compression prior to packaging the data for transfer to the spacecraft storage and subsequent downlink. LandIS also provides internal calibration sources such as blackbody, a space port, stim lamps and solar diffuser.
The Space Segment will also provide simulators for mission, ground system and interface testing during the development phase of the mission and in support of long-term maintenance of systems. These simulators will have varying fidelity and capabilities to meet various mission needs.
2.4.2 Ground Segment
The Landsat Ground Segment (GS) consists of the ground system 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), GSFC Conjunction Assessment and Risk Analysis (CARA) and its Flight Dynamics Facility, along with other external interfaces.
The Landsat 10 MOC will be used for command and control, health and status monitoring, orbit and attitude maintenance, performance analysis, onboard memory management, and flight software maintenance. The MOC will support onboard autonomy for mission planning and scheduling. The MOC ingests, processes and archives telemetry data delivered via the GN. The Landsat 10 Flight Operations Team (FOT) located at the MOC performs these functions and is responsible for monitoring the observatory, detecting, investigating and resolving spacecraft anomalies and monitoring the instrument image collections and special image collections.
The GN provides geographically dispersed ground station resources for mission execution; it includes the Landsat Ground Network (LGN) and a wideband data routing capability to the Landsat cloud. The LGN provides communication capability to and from the observatory and MOC for commanding and housekeeping data via the S-band, and will receive science mission data from the observatory over a Ka-band downlink.
The DPAS ingests, processes, and archives science data returned from the observatory via the GN. LandIS data will be processed into data products with a ground sample distance (GSD) ranging from 10m-60m depending on the particular spectral band. 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 10 data products, via a public-facing web portal for receiving data products.
The USGS will lead overall Landsat 10 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 support Landsat 10 mission readiness activities.
2.4.3 Launch Segment
The Launch Segment will provide the assets and services associated with the Launch Vehicle (LV) and the observatory-to-LV integration. The Launch Segment will include the LV; all
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
Launch Vehicle-Ground Support Equipment (LV-GSE), property, and facilities to integrate the observatory to the LV and verify its integration; and perform prelaunch testing with ground-based functions. The launch vehicle and launch site will be specified during late Mission Phase B or early Phase C.
Sections 2.0-2.4.3 were generated using Landsat 10 Common Boilerplate (L10-MGMT-DESC- 0005) Rev E
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
3.0 DESIGN LIFE
SRD-8 The spacecraft (SC) shall be designed to meet all operational requirements for a 5.25-year mission design life.
Rationale: The Landsat 10 spacecraft needs to provide operational support for at least five years to meet mission Level 1 and 2 requirements and objectives. Landsat 10 Mission life is 5 years, and commissioning period is nominally planned to be 0.25 years.
3.1 MISSION PHASES
3.1.1 Pre-Launch Phase
SRD-13 The spacecraft shall accommodate the integration, operation, and support of the Government-furnished Landsat Instrument Suite (LandIS) in accordance with the requirements specified in the Landsat 10 Spacecraft Interface Requirements Document (SCIRD), L10-SC-ICD-0002.
SRD-17 The spacecraft shall be designed to perform aliveness tests of the spacecraft and integrated LandIS while mated to the LV.
Rationale: To identify any possible ground handling problems and provide confidence in a successful mate to the LV, the spacecraft needs to perform aliveness tests that includes LandIS.
SRD-969 The spacecraft shall provide the capability to monitor battery voltage continuously from the start of combined operations with the LV through launch.
3.1.2 Launch and Early Orbit Phase
SRD-23 The Landsat 10 observatory mass, fully fueled in launch configuration, shall not exceed 4000 kilograms (kg).
Rationale: The 4000 kg maximum launch mass ensures compatibility with potential launch vehicle payload capability and the mission’s orbital insertion requirements, while maintaining required performance margins for launch vehicle structural loads, guidance, and ascent trajectory constraints.
3.1.3 Spacecraft Decommissioning Phase
SRD-32 The spacecraft shall comply with NASA Procedural Requirement for Orbital
Debris Mitigation, NPR 8715.6.
Rationale: This requirement minimizes potential for future orbital debris, minimizes non-operational lifetime on orbit, minimizes Earth impact debris footprint, and has a system capable
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
of performing any required maneuvers at end of mission design life. Inputs will be provided in support of the orbital debris assessment report (ODAR) and end of mission plan (EOMP).
SRD-33 The spacecraft shall be designed for controlled re-entry in compliance with
Process for Limiting Orbital Debris, NASA-STD 8719.14.
Rationale: This is in lieu of a natural decay (uncontrolled), retrieval, storage, earth escape or long-term re-entry method. While all of NASA-STD-8719.14 is applicable to Landsat 10, NASA-STD-8719.14 requirements 4.5-2 (small debris collisions during mission operations), 4.6- 4 (reliability of post-mission disposal operations), and 4.7-1 (limit risk of human casualty) are triggered when controlled re-entry is the selected disposal method.
SRD-34 The spacecraft shall achieve a predicted reliability of 0.9 or greater for components needed for disposal operations.
Rationale: This requirement is derived from Process for Limiting Orbital Debris, NASA-STD- 8719.14C, requirement 4.6-4 (a). To ensure that a controlled re-entry can be performed successfully at the end of the mission; the systems necessary to complete this maneuver must have a high reliability.
SRD-846 The spacecraft shall have a maximum debris casualty area (DCA) of 55 m^2.
Rationale: The DCA is defined per the Systems Technical Memo - Debris Casualty Area (DCA) Suballocation for Landsat 10, L10-SYS-TN-0001 .
SRD-42 The spacecraft shall maintain attitude control for all propulsive maneuvers including the last disposal maneuver.
Rationale: Attitude control is required for all maneuvers. The de-orbit maneuvers may be long and are likely to be affected by atmospheric drag. Attitude control is necessary to minimize impact dispersions.
3.2 ORBITS
3.2.1 Injection Orbit
SRD-37 The observatory shall operate upon insertion into the injection orbit defined in Table 3.2.1-1.
Rationale: The LV will target direct insertion of the observatory into the injection orbit, within the allowable LV dispersions.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
Table 3.2.1-1 Landsat 10 Injection Orbit Parameter Value Tolerance Mean Semi-major Axis 7026.33 km
(IO-1-1)
± 20 km
(IO-1-2)
Mean Apogee Radius 7045
(IO-2-1)
± 20 km
(IO-2-2)
Inclination 97.9835 °
(IO-3-1)
± 0.1 deg
(IO-3-2)
Argument of Perigee 90.0 °
(IO-4-1)
N/A
(IO-4-2)
Mean Local Time (MLT) of Descending Node 10:10
(IO-5-1)
± 1.0 minute
(IO-5-2)
This table was made from the Landsat 10 Common Orbit Injection Table L10-SYS-DESC-0036 Rev A
3.2.2 Operational Orbit
SRD-39 The spacecraft shall operate in a Sun-synchronous, near circular, frozen orbit with the orbital parameters as defined in the Landsat 10 Operational Orbit Table 3.2.2-1.
Rationale: The orbit defined in this requirement produces an orbit that follows the Worldwide Reference System-3 (WRS-3) Grid.
Table 3.2.2-1 Landsat 10 Operational Orbit
Parameter Value Allowable Variation Equatorial Altitude 653 km
(OO-1-1)
± 1.0 km
(OO-1-2)
Inclination (True – of – Date) 97.9835 °
(OO-2-1)
± 0.1°
(OO-2-2)
Mean Eccentricity (Brouwer-Lyddane) 0.00116
(OO-3-1)
<=0.00125
(OO-3-2)
Across track, ground track error at the descending node
0.0 km
(OO-4-1)
± 5.0 km
(OO-4-2)
Mean Local Time at Descending Node 10:10
(OO-5-1)
± 5 minutes
(OO-5-2)
Ground Track Spacing at Equator 151 km
(OO-6-1)
Mean Semimajor Axis 7026.33 km
(OO-7-1)
± 1.0 km
(OO-7-2)
Mean Argument of Perigee (deg) 90.0°
(OO-8-1)
Altitude Range 651 to 681 km
(OO-9-1)
This table was made from the Landsat 10 Common Operational Orbit Tables L10-SYS-DESC-0019 Rev A
3.2.3 Disposal Orbit
SRD-41 The spacecraft shall achieve a perigee altitude of 50-km or less at the end of the final re-entry burn.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
Rationale: To minimize the dispersions associated with the re-entry footprint, it is necessary to achieve a re-entry angle of attack large enough to ensure capture and prevent any atmospheric skipping of the observatory.
3.3 IMAGING SUPPORT
SRD-49 The spacecraft shall continuously provide capability that supports all imaging and calibration activities required to meet mission objectives as defined in the Landsat 10 Design Reference Case – 18 Days (DRC-18) Definition, LSDS-2389.
SRD-50 The spacecraft shall support acquisition of off-nadir images, up to 15 degrees cross-track.
Rationale: For rapidly changing conditions on the earth, Landsat 10 will be able to image up to 15 degrees off-nadir left or right of the orbital track.
SRD-51 The spacecraft shall support the acquisition of at least 9 minutes of continuous off-nadir imaging within a single orbit period.
Rationale: The distance across the conterminous United States is approximately 18 scenes.
Continuous long-duration off-nadir imaging will likely not be used extensively during operations.
SRD-52 The spacecraft shall support the acquisition of at least 36 minutes of continuous nadir-pointing daylight imaging within a single orbit period.
SRD-53 The spacecraft shall support the acquisition of at least 15 minutes of continuous nighttime imaging within a single orbit period.
NOTE: that there will always be a gap of no imaging sequences between daylight only imaging sequences or between daylight and nighttime imaging sequences, where the imaging needs to be able to start without a need to restabilize the thermal conditions prior to an imaging sequence to start.
3.4 SPACECRAFT OPERATIONS
3.4.1 Spacecraft Modes
SRD-56 The spacecraft shall be capable of being commanded into any operational mode or sub-mode.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
Rationale: Allows for operational flexibility. Also clarifies valid ground commandable transitions. (e.g., Not possible to command the spacecraft into the launch mode). The full suite of available modes and sub-modes will be defined by the spacecraft vendor.
SRD-1224 The spacecraft shall have a power-positive, thermally safe, optically safe control mode (safe hold) with the following characteristics:
(1) Safety should not be compromised by the same credible fault that led to safe hold activation
(2) Employ the minimum hardware set required to maintain a safe attitude.
(3) Not require ground intervention to achieve or maintain for mission design life.
Rationale: The spacecraft must be able to achieve and maintain safe hold mode such that it may span multiple seasonal transitions / environments and not be dependent on ground commanding.
SRD-57 The spacecraft shall autonomously transition from launch mode to safe hold mode upon separation from the Launch Vehicle (LV)
Rationale: The spacecraft needs to be able to achieve a safe operating condition at separation from the LV.
SRD-61 The spacecraft shall transition out of the safe hold mode only via ground command.
Rationale: To ensure the safety of the observatory, it is critical that the spacecraft does not exit safe hold mode autonomously.
3.4.2 Operational Contingency Response
SRD-65 The spacecraft shall continuously monitor its state-of-health (SOH) data, detect out-of-limit conditions, and autonomously respond to these out-of-limit conditions by configuring an appropriate safe state for LandIS and/or spacecraft systems, without ground support.
Rationale: In the event of a failure in established communications, whether onboard the spacecraft or in the ground system, the spacecraft can respond appropriately without ground intervention. This may be achieved through autonomous fault management sequences, which result in the spacecraft initiating safing sequence(s), or other self-management activities which preserve observatory health and safety such as autonomous transition to Sun-pointing, or load shed activities to power off non-essential units in the event of a fault.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
SRD-66 The spacecraft shall detect, flag, report, and respond to out-of-limit conditions or other abnormal affects caused by external sources of Radio- Frequency Interference (RFI), particularly in the Radio Frequency (RF) communications, Global Positioning System (GPS), attitude control, and power subsystems, within 10 minutes of occurrence.
Rationale: NASA's proactive response to space asset protection is that it is desirable for spacecraft to report unusual events that might indicate malicious as well as accidental/inadvertent activity. As an example, if an SC receiver experiences a very high input signal around the mission frequency, this may indicate an attempt to interrupt normal operations. By capturing the time of the event, it is possible to identify the area of the occurrence. L10-SYS-PLAN-0027, Landsat 10 Project Protection Plan will define relevant threats and mitigations that the mission will address. It is desired to detect and react quickly to any interference events and recover within an orbit whenever feasible.
SRD-1245 A power-on reset occurrence shall be unambiguously identifiable via telemetry.
Rationale: An unexpected power-on reset could be an indication of a serious issue and should be able to be distinguished from resets that are indicative of less serious conditions.
3.5 REDUNDANCY AND SINGLE-FAULT TOLERANCE DESIGN REQUIREMENTS
SRD-68 The spacecraft shall be designed such that no single credible failure of any mechanisms, thermal, and power systems that support the mission data chain permanently preclude the spacecraft from meeting all mission data acquisition, processing, storage, and wideband transmission requirements throughout the design life.
Rationale: Credible is defined as having a probability of occurrence greater than 0.001 for on-orbit technical risks. Probability assessments used to characterize credibility must utilize high-confidence statistical methods (e.g., on-orbit history, test data, physics of failure assessments, etc.).
SRD-1144 The spacecraft shall be designed such that there are no single credible failures within any system required to execute controlled re-entry.
Rationale: Credible is defined as having a probability of occurrence greater than 0.001 for on-orbit technical.
SRD-878 The spacecraft shall include 50% additional memory in the mass storage system to be used as redundant, cold spare memory in the event of memory failures.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
Rationale: This redundant memory is additional memory which is necessary to meet all storage, lifetime, and capacity including accounting for end of life sizing (EOL) requirements as specified in Section 3.15.4.
SRD-69 The spacecraft shall preclude the propagation of spacecraft component, spacecraft subsystem, or LandIS failures, to other spacecraft components, spacecraft subsystems, or to LandIS.
Rationale: This includes precluding failure propagation to redundant sides of a system.
SRD-74 The spacecraft shall provide the capability of switching between the primary and the backup unit for redundant systems by command.
Rationale: This should allow the spacecraft to switch back and forth between all primary and backup units through command.
3.6 FAULT MANAGEMENT
SRD-80 In the event of a failure that meets established failure criteria, the spacecraft shall autonomously switch to the backup component of redundant systems only as required to ensure observatory safety, and to enable the observatory to achieve safe hold mode.
Rationale: To ensure survivability in either the safe hold mode or the Earth-point sub mode, the spacecraft should be able to switch to a back-up element of a redundant system. There is no requirement for autonomous switching to support nominal imaging operations.
SRD-81 The spacecraft shall preclude autonomously switching to a known failed redundant component.
Rationale: Switching to a known failed component is likely to be a threat to health and safety.
SRD-83 The spacecraft shall provide the capability of overriding autonomous functions via ground command. (Note: This does not include one-time protective hardware devices such as electrical fuses, etc.)
Rationale: The ground may need to override or suspend an autonomous response to ensure observatory safety.
SRD-84 The spacecraft shall report autonomous reconfigurations in SOH and stored state-of-health (SSOH) telemetry.
Rationale: Whenever the state of a hardware configuration is changed, it needs to be tracked and reported in telemetry.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
SRD-85 The spacecraft shall send a command to alert LandIS to an unsafe condition upon detection of as agreed to off nominal spacecraft conditions.
Rationale: LandIS must be alerted of any spacecraft mode changes from nominal to off-nominal or detected power, attitude, field of view fault, etc., problems so LandIS can elect to perform a self-protection as necessary. The list of conditions will be worked collaboratively between government, LandIS, and spacecraft, and documented in ICDs or related documentation (e.g.
constraints documentation).
SRD-1131 The spacecraft shall command LandIS into a known configuration in the event of any failures in the execution of operational autonomy.
Rationale: This does not preclude operational autonomy functions from coordinating with fault management (FM) to achieve the known and safe configuration for LandIS.
SRD-1132 The spacecraft shall perform onboard autonomy functions on a non-interference basis with the fault management functions.
Rationale: It is critical that fault management functions always take precedence over operational autonomy and no fault management functions are either modified or acted upon by operational autonomy functions to ensure the health and safety of the observatory.
SRD-227 The spacecraft shall perform table-driven fault management functions to check thresholds and persistent values on specific data items.
Rationale: Allows for threshold changes as the SC ages (e.g., to prevent nuisance triggers).
3.6.1 Telemetry Monitoring
SRD-88 The spacecraft shall autonomously monitor and respond to spacecraft and
LandIS SOH telemetry out-of-limit violations by execution of pre-defined, ground-configurable stored command sequences that safe the component, spacecraft, LandIS, or observatory.
Rationale: To provide a response based on changing states within the spacecraft.
SRD-89 The spacecraft shall support a ground-configurable telemetry monitoring capability, which can trigger a stored command sequence.
Rationale: The monitoring of SOH parameters in telemetry, such as power, temperature, operations of sub-systems, provides the information necessary to permit the spacecraft to take autonomous actions. Telemetry Monitors (TMONs) are useful in operations and troubleshooting to look at specific telemetry (TLM) points and execute actions when they exceed a specific value. This telemetry monitoring (TMONs) will be changed by ground command during operations. Either the SOH parameter or the action taken because of a change in the parameter
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
will be changed by command. They are programmable from the ground to provide flexibility in addressing nominal and anomalous operations.
SRD-92 The spacecraft shall allow for definition and modification of telemetry monitors on orbit via table upload.
Rationale: Telemetry monitors (TMONs) need to be easily updated and changed by the ground to provide operations flexibility to adapt to changes in the observatory over mission life. Updates must be simple to change via table load and not require software patches or compiled code to update.
3.7 AVAILABILITY
SRD-99 The spacecraft shall support all mission observations without interruption during each 18-day cycle.
Rationale: There should not be any subsystem on the spacecraft that needs maintenance that interferes with the mission observations.
3.8 DATA LOSS
SRD-598 Over any 18-day cycle throughout the mission life, the spacecraft shall have no data corruption or mission data chain failures that leads to more than 0.15% loss of mission data over the life of the mission.
Rationale: The data loss allocation in this requirement is a portion of the total allowable data loss at the mission level that is allocated specifically to the spacecraft. The combination of spacecraft, LandIS, and ground system data loss allocations sum to the total mission-level data loss requirement. The spacecraft allocation only pertains to the spacecraft itself, starting from the spacecraft side of the LandIS to Spacecraft interface through transmitter output. Unsuccessful ground receipt due to ground misconfiguration, lack of ground station availability due to orbit geometry, or other ground-based events that are no fault of the spacecraft do not count against this data loss allocation. Similarly, errors caused by LandIS or failure of LandIS to deliver data to the SC interface are not counted in this allocation. This data loss only pertains to loss due to spacecraft system issues or failures. Data loss is measured over a quarterly basis.
3.9 STRUCTURAL AND MECHANICAL SYSTEMS
SRD-120 The spacecraft design shall permit full range deployment of all Landsat 10 mechanisms during ground processing.
Rationale: All deployments will be tested after the spacecraft is fully integrated. At a minimum this should be done in ambient conditions.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
3.9.1 Mechanisms and Deployable Design Requirements
SRD-123 The spacecraft mechanisms and mechanisms components shall be implemented in compliance with all sections of Design and Development Requirements for Mechanisms, NASA-STD-5017, with the noted exception of Section A.2.8, Quick-Release Pins.
Rationale: Clarification on the noted exception of Section 4.17 Quick-Release Pins. Quick-release pins are not allowed to be used on Landsat 10 for in-flight purposes, although they may be used in ground support equipment.
3.10 THERMAL SYSTEM
SRD-141 The spacecraft design shall maintain all components within their operational or survival temperature limits (whichever is appropriate) during all known mission modes, maneuvers, attitudes, and states.
SRD-143 The spacecraft shall provide heater power and the required thermal interface conditions for LandIS to maintain its components within survival allowable flight temperature limits in all modes and while in launch configuration.
SRD-145 The spacecraft thermal control system shall monitor and report the spacecraft subsystem temperatures in SOH and SSOH telemetry.
Rationale: Tracking and trending spacecraft temperatures is important to the longevity of the mission.
SRD-147 For spacecraft thermal control system hardware implemented with reprogrammable set points, those set points shall be adjustable by command.
Rationale: For implementations using reprogrammable devices, this can leverage on-orbit knowledge of observatory performance in space environment to optimize observatory thermal performance through device set point management capability.
SRD-847 Health and safety temperature sensors shall be conditioned to provide a voltage range that represents a temperature range to include a margin of greater than or equal to 5ºC beyond the unit qualification or non- operational survival limit, whichever is greater.
Rationale: Ensure that sensor range has adequate margin to prevent saturation during qualification testing and worst-case flight predicts.
SRD-848 Temperature sensor design shall not include linearizing resistors at the thermistor readout location (co-located with the sensor), by design.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
Rationale: Temperature reading accuracy is adversely affected as linearizing resistor value varies with temperature change.
SRD-148 All spacecraft heater circuits shall be fully redundant.
SRD-149 The spacecraft thermal control subsystem operation shall be fully autonomous after on-orbit initialization.
3.11 ELECTRICAL SYSTEM
3.11.1 Energy Collection and Storage
SRD-680 The spacecraft shall provide multi-level load shedding control to protect the battery against depth of discharge (DoD) that is unrecoverable or shortens battery life beyond mission lifetime.
Rationale: In the event of a spacecraft anomaly, power shedding may be necessary to safe the spacecraft and protect performance of the battery throughout the mission. Load shed levels will be determined in conjunction with Project FM and Electrical Systems Lead.
SRD-683 The spacecraft shall autonomously return to a battery maximum state of charge condition by the end-of-sunlight portion of the orbit, under max power draw science case conditions (e.g., science configuration longest imaging path and night imaging) at end of mission life.
Rationale: To ensure that the power system is sized to handle all loads, including recharging the battery fully before the start of eclipse conditions, with appropriate margin at EOL.
SRD-689 The spacecraft battery shall be designed to meet all power requirements throughout the mission lifetime with a lifetime margin of at least 20%, on expected discharge cycles.
Rationale: Properly size the battery to support power availability and battery discharge during all phases of the mission.
SRD-692 The spacecraft power system shall monitor and report all battery cell voltages for a large cell battery in spacecraft SOH telemetry.
Note: A battery that is comprised of equal to or greater than 10 cells is considered a large cell battery.
Rationale: Telemetering of battery cell voltages is required for proper assessment of battery performance as spacecraft mission life directly depends on the performance of the battery.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
SRD-694 The spacecraft shall provide electrical power for all spacecraft operational modes during eclipse conditions.
Rationale: LandIS will be operational even during eclipse, and power systems should be designed to provide power for all operational modes during eclipse conditions. Battery sizing will consider the operational aspects of the mission and have sufficient margins to support an end-of-design-life needs.
SRD-851 The spacecraft shall be capable of being powered via electrical ground support equipment (EGSE) power supply, through the umbilical interface, with or without batteries on the power bus.
Rationale: To support flexibility during integration and test phase, as well as ground processing while at launch site.
SRD-1073 The spacecraft shall provide umbilical hardline monitor telemetry for battery voltage, battery current, battery temperatures, and power bus current, accurate to within 1% of expected full range.
Rationale: Allows independent monitoring at higher sample rate than available in telemetry, for diagnosis and assessment of anomalies and mishaps.
SRD-852 The spacecraft shall be capable of having the battery electrically connected and disconnected from the power bus during ground processing, without damage or degradation of flight hardware
Rationale: To ensure that devices and methods used in the connecting and disconnecting of the batteries during test will limit arcing, transients and endure planned number of connect/disconnect cycles.
SRD-696 The spacecraft shall provide overcurrent protected, commandable power services for all switched loads.
Rationale: To provide adequate control of loads and fault protection of the power subsystem.
3.11.2 Power Distribution and Monitoring
SRD-708 The spacecraft design shall include power distribution for selecting, connecting, and disconnecting the LandIS and selected spacecraft equipment to/from the power bus.
Rationale: To reconfigure the spacecraft because of mode changes or failover to redundant units.
SRD-710 The spacecraft shall monitor and report in SOH telemetry the power bus voltage and current.
Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.
Rationale: Monitoring state of health.
SRD-714 The spacecraft design shall provide power services routed with power and power returns in twisted shielded harness groups, with integral or overwrap shields terminated to the backshell.
Rationale: This requirement is driven by the Electromagnetic Interference (EMI)/ Electromagnetic Interference (EMC) requirements.
SRD-716 The spacecraft shall ensure that, for cross-strapped redundant power services that share return lines, harness designs twist the wires from both power services within a single twist group or, when separate twist groups are used, that those groups are hand-twisted together to maintain group twist over the maximum practical length given connector separation.
Rationale: A current imbalance is created wherever a single cross-strapped service is energized, such that only energized power conductors carry current, but both power services share the return current. This may create magnetic dipoles and other EMI effects.
SRD-723 The spacecraft shall telemeter the on/off state of all operational and survival power services.
Rationale: This telemetry allows to know the spacecraft configuration at any time. Furthermore, it helps in anomaly resolutions.
SRD-725 The spacecraft shall monitor and report, in SOH telemetry, the current for each power service with a resolution of 10 mA or 1% of specified load peak current, whichever is greater.
Rationale: Allows health and safety monitoring and trending of load power.
SRD-727 The spacecraft design shall include unswitched power services for components (e.g., S-band receivers) that must always be powered on.
Rationale: Prevents unrecoverable loss of critical components (e.g., receiver) due to inadvertent power off.
SRD-729 The spacecraft design shall not specifically fault protect unswitched power services.
Rationale: Prevents unrecoverable loss of critical components (e.g., receiver) due to inadvertent trip of fault protection.
Use or disclosure…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .