LMX_PhA_PORD_v10.pdf

GeoXO Lightning Mapper Instrument Performance Operational

Requirements Document (PORD)

Contents 1 Scope

1.1 Identification

1.2 Mission Review

1.3 Document Overview

1.4 Terminology

1.5 Definitions

1.6 Requirements Applicability

2 Documents

2.1 Applicable Documents

2.2 Reference Documents

3 Sensor Requirements

3.1 Functional Requirements

3.1.1 LMX Modes

3.1.2 On-Orbit Operations

3.2 Performance Requirements

3.2.1 Coverage

3.2.2 Event Navigation

3.3 Design Requirements

3.3.1 Reliability

3.3.2 Mechanical Requirements

3.3.3 Thermal Requirements

3.3.4 Onboard Processors Requirements

3.3.5 Flight Software Requirements

3.3.6 Power Requirements

3.3.7 Magnetic Properties

3.3.8 (Reserved)

3.3.9 Ground Support Equipment and Development Facilities

4 Design Verification Requirements

4.1 Performance Operating Time and Trouble-Free Performance Testing

4.2 Structural and Mechanical Verification Requirements

4.2.1 Mechanical Test Factors and Duration

4.2.2 Minimum Workmanship

4.2.3 Testing in Flight Configuration

4.2.4 Structural Proof Testing

4.2.5 Modal Survey Characterization

4.2.6 Structural Qualification

4.2.7 Deployment and Articulation Verification

4.2.8 Life Test

4.2.9 Mechanical Clearance Verification

4.3 Electromagnetic Compatibility Requirements

4.3.1 General

4.3.2 Electrostatic Arc-Discharge Susceptibility

4.4 Magnetic Properties

4.4.1 General

4.5 Thermal Requirements

4.5.1 General

4.5.2 Thermal Vacuum

4.5.3 Thermal Cycling

4.5.4 Thermal Balance (TB)

4.6 Test Condition Tolerances

4.6.1 General

1 Scope

1.1 Identification

This Performance and Operational Requirements Document (PORD) sets forth the performance requirements for the National Oceanic and Atmospheric Administration (NOAA) GeoXO (Geostationary and Extended Observations) Lightning Mapper (LMX) instrument.

1.2 Mission Review

The LMX is a single spectral channel instrument used to measure the location and intensity of optical transients produced by lightning as part of a 3-axis stabilized, geostationary satellite system. The LMX remotely collects data over the Earth disk visible from geostationary orbit for severe weather forecasting, hazard warning, and public safety alerts.

The LMX objective is to provide NOAA Lightning Mapper operational data that will be used by NOAA and other public and private agencies to produce forecasts of severe weather and to issue warnings for public safety.

The LMX provides data to the Ground System via the spacecraft communication system. The Ground

System takes the LMX data, spacecraft telemetry data, orbit determination data and other required information and autonomously generates radiometrically calibrated and navigated data (Level 1b data) for the NOAA users.

The Ground System will be procured by the Government but will implement algorithms developed by the LMX contractor to satisfy performance requirements. The Ground System will calibrate and then resample the data to generate the fixed grid. Resampling requires that the raw imagery be adequately sampled to maintain radiometric accuracy after resampling.

1.3 Document Overview

This document contains all performance requirements for the LMX instrument and Ground Support

Equipment (GSE). This document, the General Interface Requirements Document (GIRD) and the LMX

Unique Instrument Interface Document (UIID) define all instrument to spacecraft interfaces for the LMX instrument.

1.4 Terminology

The use of “shall” designates a requirement that must be met.

The use of “should” designates good practice.

The use of “will” is a statement of fact.

The use of “may” designates permission by the Government.

The term “(TBD)” means “to be determined” and is used when no value is available, and subsequent vendor study will be needed to obtain it.

The term “(TBR)”, which means “to be refined/reviewed”, means that the requirement is subject to review for appropriateness and subject to revision. The contractor is liable for compliance with the requirement as if the “TBR” notation did not exist. The “TBR” merely provides an indication that the value is more likely to change in a future modification than requirements not accompanied by a “TBR”.

The term “(TBS)”, which means “to be supplied”, means that the government will supply the missing information in the course of the contract. These serve as a placeholder for future requirements. The contractor is not liable for compliance with these “placeholder” requirements, as insufficient information is provided on which to base a design.

1.5 Definitions

Throughout this document, the following definitions apply:

Accuracy: Refers to the error in a measurement that is the difference between the measurement result and the object to be measured (the measured or true value). It includes both systematic and random errors. Systematic errors must be estimated from an analysis of the experimental conditions and techniques. Random errors can be determined, and reduced, through repeated measurements under identical conditions.

Albedo: Refers to the fraction of the solar spectrum taken from the default MODTRAN solar irradiance file, version 4V1R1 (newkur.dat) that is reflected by the Earth at the top of the atmosphere assuming a

Lambertian surface.

Background: Best estimate of the current mean radiometric value of a detector sample.

Background Image: A scene composed of the background from all detector elements in the focal plane.

Channel: A measurement that is an aggregate of one or more spectral samples that meets or exceeds

LMX requirements.

Collection: The set of all frames from all telescopes for a single integration period.

Detector noise: 1-sigma noise level required to meet the Signal-to-Noise Ratio (SNR) specification.

Detector sample or element: Refers to the output of a physical detector after the Analog-to-Digital converter (ADC).

Eclipse: Defined as when the solar disk is completely occulted by the Earth or Moon, as viewed from the

GeoXO satellite.

Event: The occurrence of a detector sample exceeding the threshold (not to be confused with event logging or event messages) due to a signal transient. Events may include but are not limited to:

a) Optical lightning events

b) Radiation-induced events

c) Surface glint-induced events

d) Electronic noise-induced events

e) Jitter-Induced events

Fixed Grid Format: Refers to the idealized georeferenced positions for pixel locations. The fixed grid has the following characteristics:

a) The fixed grid is rectified to a GRS80 geoid viewed from the idealized geostationary position.

b) The pixels have the same angular separation for East/West and North/South.

c) From the viewpoint of a right-hand coordinate system of the idealized geostationary satellite with its x-axis in the direction of the velocity and the z-axis pointed at nadir, the

North/South angle is determined by a rotation about the x-axis and the East/West angle is determined by a rotation about the rotated y-axis.

d) The angular separation is 112 by 112 microradians for 4 by 4 km resolution at nadir.

e) The ideal sub-satellite point is at the corner of a pixel on the 112 microradians grid.

f) The ideal geostationary satellite position vector uses the ideal satellite as the viewpoint.

Fully Functional Configuration: Being able to perform the following functions: Lightning optical pulse detection, sensor health and status data acquisition, CCSDS packet generation (science, health and status data) plus command reception and execution.

Frame: The set of all samples from one focal plane array for a single integration period.

Full Disk: The entire Earth disk as observed from geostationary orbit.

Geolocation: Determination of sample locations on the Earth surface (GRS80 geoid) in terms of latitude and longitude.

Level 1b Data: Optical lightning events that have been calibrated, navigated (to the fixed grid) and time tagged.

Navigation: Refers to the determination of the location of each pixel relative to a fixed reference, such as fixed-grid angle coordinates.

Navigation Error: Refers to the angular error of locations in the resampled fixed-grid frame.

Pixel: Applies to data samples after resampling during the ground processing.

Precision: Refers to the standard deviation of a statistically meaningful number of samples of a measurement.

Pulse: An optical signal generated by lightning whose nominal duration is on the order of 1 ms. A pulse, as viewed by the LMX, can generate one or more optical events, distributed spatially and or temporally.

Radiant Energy: The integral of object radiance at the entrance aperture over the instrument integration time. The preferred units are joules (J).

Registration: Refers to maintaining the spatial relationship between pixels within frames, between frames, across multiple telescopes.

SNR: Signal-to-Noise Ratio

Threshold: Minimum amount which a detector sample must exceed the mean value of the background signal for an event to be detected.

Unit: A functional subdivision of a subsystem and generally a self-contained combination of items performing a function necessary for the subsystem's operation. Examples are electronics unit and sensor unit.

1.6 Requirements Applicability

The requirements in this LMX PORD pertain to the LMX ‘system’, which include optics, detectors, electronics, software, and ground processing.

All requirements apply over the entire life of the instrument.

The initial phase of ground processing (Level 1b) is to discriminate optical transient signals (lightning events) from the totality of events.

Data performance requirements, such as event navigation, decompression, and calibration apply to data after Level L1b ground processing.

2 Documents

2.1 Applicable Documents

The following documents form a part of this specification to the extent specified herein.

1. LMX Unique Instrument Interface Document, NASA-GSFC, 418-XO-LMXUIID-0067

2. General Interface Requirements Document, NASA-GSFC, 418-XO-GIRD-0025

3. CCSDS Recommended Standard for Lossless Data Compression, CCSDS 121.0-B-3, August 2020

4. CCSDS Recommended Standard for Image Data Compression, CCSDS 122.0-B-2, September

2017.

5. Structural Design and Test Factors of Safety for Spaceflight Hardware, NASA, Document Number

NASA-STD-5001B, August 6, 2014

6. General Environmental Verification Specification for GSFC Flight Programs and Projects, GSFC- STD-7000A, April 22, 2013.

7. NASA-STD-8719.24, NASA Expendable Launch Vehicle Payload Safety Requirements (Base and Annex), 2018

2.2 Reference Documents

The following documents provide reference material for part of this document.

1. General Specification for Assemblies, Moving Mechanical, for Space and Launch Vehicles, MIL-A- 83577B, February 1, 1988

2. Space Mechanisms Handbook, Document Number NASA TP-1999-206988

3. CCSDS Informational Report Concerning Lossless Data Compression, Green Book, CCSDS 120.0-

G-2 April 2013

4. Dual Geostationary Lightning Mapper Observations, S.D. Rudlosky, K.S. Virts, AMS Monthly

Weather Review, Volume 149 Issue 4, https://doi.org/10.1175/MWR-D-20-0242.1, pp. 979–

998, April 2021

5. Algorithmic Chain for Lightning Detection and False Event Filtering Based on the MTG Lightning Imager”, Pierre Kokou et al., IEEE Transactions on Geoscience and Remote Sensing, vol. 50, no.

9, 5115 – 5124, 2018

6. Optical Observations of Lightning from a High-Altitude Airplane, H.J. Christian and S.J. Goodman, J. of Atmospheric and Oceanic Technology, vol. 4, December 1987, pp. 701-711

7. The Detection of Lightning From Geostationary Orbit, Hugh J. Christian, Richard J. Blakeslee and

Steven J. Goodman, J. of Geophysical Research, vol. 94, no. D11, September 1989, pp. 13329-

13337

8. Laboratory Calibration of the Optical Transient Detector and the Lightning Imaging Sensor, William J. Koshak, Mike F. Stewart, Hugh J. Christian, James W. Bergstrom, John M. Hall, and

Richard J. Solakiewicz, J. of Atmospheric and Oceanic Technology, vol. 17, July 2000, pp. 905-915.

9. Lightning optical pulse statistics from storm overflights during the Altus Cumulus Electrification

Study, D.M. Mach, R.J. Blakeslee, J.C. Bailey, W.M. Farrell, R.A. Goldberg, M.D. Desch, and J.G.

Houser, Atmospheric Research 76 (2005), pp. 386-401 https://doi.org/10.1175/MWR-D-20-0242.1

3 Sensor Requirements

3.1 Functional Requirements

3.1.1 LMX Modes

The contractor may propose additional modes and add additional capabilities and functions.

3.1.1.1 Safe Mode

The LMX shall implement a Safe Mode which is a thermally, electrically and optically safe configuration that protects the instrument from the spacecraft and the environment.

The LMX shall enter Safe Mode upon receipt of a ground command, receipt of an autonomous safe mode command from the observatory, or detection of internal faults that could cause damage to the instrument

The LMX shall be maintainable in Safe Mode for an indefinite period of time.

Rationale: The LMX needs a Safe Mode for contingency operations

3.1.1.2 Normal Operational Mode

The LMX shall be in a fully functional configuration while in Normal Operational Mode.

Rationale: Normal mode is used for observations that require full functionality.

The LMX shall meet all performance requirements while in Normal Operational Mode without receiving commands or data loads for a minimum of 7 days.

Rationale: Autonomy is required for a period of 7 days, without impacting performance.

3.1.1.3 Diagnostic Mode

The LMX shall implement a Diagnostic Mode.

The LMX shall enter Diagnostic Mode only on command.

The LMX shall be in a fully functional configuration while in Diagnostic Mode.

Rationale: Diagnostic mode is needed for diagnosing anomalies.

The LMX shall by command send background images at increased cadence not to exceed the maximum data rate specified in the LMX UIID while in Diagnostic Mode.

Rationale: Diagnostic mode will afford commandable sampling engagement for diagnosing anomalies.

Fill data bandwidth with background images, no events. Or downlink specific detector sample from every data frame.

If the data is compressed, LMX shall by command send the same data both compressed and uncompressed while in Diagnostic Mode.

Rationale: Diagnostic mode will send compressed and uncompressed to help in validation and in assessing anomalies.

The LMX shall by command send dwell data (increased samples per second of a particular telemetry measurand) while in Diagnostic Mode.

Rationale: Diagnostic mode dwell data will help in validation and in assessing anomalies.

3.1.1.4 Survival Mode

The LMX shall implement a Survival Mode in which all power is off (except for spacecraft provided survival heater power) and only passive telemetry is available.

3.1.1.5 Mode Transitions and Commands

The LMX shall transition from any defined mode to any other defined mode upon command.

The LMX shall execute commands to individually enable and disable each autonomous function.

Rationale: Autonomous capability needs to be able to be disengaged as well.

The LMX shall initiate all commanded mode transitions in no more than 20 seconds after receipt of command.

Rationale: Mode transitions should occur rapidly for operators.

The LMX shall make limits and triggers of autonomous functions changeable by command.

Rationale: Autonomous functions should be controlled by operators if there is a special need to do so.

The LMX shall transition from its current mode to any other mode without causing permanent damage to itself.

Rationale: Mode transitions should occur without damage.

The LMX shall indicate the mode of the instrument in housekeeping telemetry.

Rationale: Knowledge of instrument modes is needed for data processing.

The LMX shall provide command and housekeeping telemetry functions in all powered modes.

Rationale: Command and housekeeping telemetry is necessary for monitoring instrument health at all times.

Receipt and processing of commands and data shall not interfere with LMX data collection in any mode.

The LMX shall provide an event detection threshold that is adjustable by command.

3.1.2 On-Orbit Operations

3.1.2.1 Operational Zone

The LMX shall meet all operational and performance requirements over the full field of view, except for

ZRDQ.

3.1.2.1.1 Zones of Reduced Data Quality (ZRDQ)

The LMX shall meet all performance requirements for all samples whose distance from any part of the uneclipsed Sun and any part of the uneclipsed Sun rotated 180° about the instrument boresight is greater than 5° (TBR).

3.1.2.2 Imaging the Sun

The LMX shall survive imaging of the sun without sustaining damage.

Rationale: imaging of the sun or unexpected loss of pointing control that points at the sun must not result in damage to the instrument.

3.1.2.3 Eclipse

The LMX shall operate continuously through eclipse periods.

3.1.2.4 Operations After Maneuvers

3.1.2.4.1 Yaw Flip

The LMX shall meet all SNR, coverage and navigation requirements after spacecraft attitude has been within specification for 30 minutes following a yaw-flip.

Rationale: If the spacecraft executes a yaw flip, the instrument recovery will occur in this duration after the interface is restored to nominal conditions.

3.1.2.4.2 Station Keeping

The LMX shall meet all SNR, coverage and navigation requirements after spacecraft attitude has been within specification for 30 minutes following a station-keeping maneuver.

Rationale: If the spacecraft executes a different maneuver than a yaw flip, the instrument recovery will occur in this short duration after the interface is restored to nominal conditions.

3.1.2.4.3 Post Storage Activation

The LMX shall meet all requirements within 2 days (TBR) of LMX turn-on after being in on-orbit storage, except navigation.

Navigation shall meet all requirements after 3 days (TBR) of LMX turn-on after being in on-orbit storage.

Rationale: After activation, spectral filters require thermal stabilization. Navigation may require coastline identification or landmarking data.

3.1.2.5 Outgas Period

The LMX will sublimate and evaporate contaminants from hardware to prevent contamination from jeopardizing performance.

The post-launch outgas period shall be no longer than 14 days.

Rationale: Outgassing should occur relatively quickly to afford time for PLT testing in 6 months.

3.2 Performance Requirements

3.2.1 Coverage

LMX shall view the entire Earth disk as observed from geostationary orbit.

3.2.1.1 Coverage Rate

The LMX shall provide continuous optical transient pulse detection over full-disk at a cadence between

500 Hz to 1000 Hz.

Rationale: The LMX revisit of the entire region occurs continuously with a rapid cadence to the optical transients associated with lightning.

3.2.1.2 Simultaneity

The LMX shall time tag each event to an accuracy of 0.5 msec.

Rationale: Precision is needed for lightning event clustering.

3.2.1.3 Data Latency

The LMX shall contribute no more than 10 seconds to the total data latency from event detection through generation of Level 1b products.

Rationale: Data latency is measured from the time the instrument acquires all samples for a scene to the time the events are available for dissemination on the ground. The LMX contribution to data latency includes delay of delivery of data to the spacecraft and delay due to ground algorithm processing (i.e., resampling and INR).

Rationale: Latency between the last observation of the input data to the level 1b processing and the availability of the data for further processing should be as short as practical.

3.2.1.4 Data Collection Output

The LMX shall collect each pixel from multiple detector frame samples contained within a single collection.

Rationale: Identify same events in overlap region. Need one report per event, even if sample from multiple detectors. A collection is the set of all frames from all telescopes for a single integration period.

A frame is the set of all samples from one detector for a single integration period.

3.2.1.5 Lightning Detection

The LMX shall provide the radiant energy of each event with associated data needed by ground processing to detect each event.

Rationale: Provide detection threshold, surrounding pixels, background, detector element, false event filter data, etc.

The event detection probability shall be greater than 70% (TBR) after Level 1b processing per the Table 1 lightning distribution spectrum. The time span for this computation is 24 hours.

Table 1 Lightning Distribution Spectrum

Percent Detected Energy Density uJ/m2/sr

95 3.8 (extrapolated)

90 4.5

85 5.1

80 5.9

75 6.7

70 7.6

65 8.7

60 9.9

55 11.3

50 12.9

45 16.6

40 18.1

The false event probability shall be less than 5% (TBR) after Level 1b processing. This includes radiation

(cosmic rays), cross talk. The time span for this computation is 24 hours.

The readout of a background image (if applicable) shall not interfere with the detection and reporting of events.

The LMX shall be able to detect events in the same detector element in consecutive frames.

3.2.1.6 Spectral Response

The LMX system spectral response shall have a spectral range sufficient to collect the lightning signal associated with the oxygen triplet centered near 777.4 nm per Table 2. The FWHM of the spectral filter will be near 0.7 to 0.8 nm at a field angle near 0°.

Table 2. Oxygen emission line spectral locations and relative intensities associated with lightning to be detected by the LMX instrument.

λ (nm, air) λ (nm, vac)

Normalized Relative Intensities

Oxygen triplet

777.196 777.408 0.358

777.418 777.630 0.333

777.540 777.753 0.309

Mean Wavelength

777.376 777.589

Rationale: LMX must discriminate a small lightning signal on top of a large background signal, so the spectral response envelope must be large enough to collect the lightning signal and small enough to avoid collecting too much background signal.

3.2.1.7 SNR

The LMX shall observe daytime lightning events with a minimum SNR of 4 across the field of view for:

- Dim lightning signal level of 3.44x1013 photons/m2/sr. This photon energy density is equal to 8.8 µJ/m2/sr.

- Background of 1.47x1021 photons/s/m2/sr/µm. This photon radiance is equal to a Lambertian reflector with solar illumination at 777.4 nm.

The LMX shall observe nighttime lightning events with a minimum SNR of 4 across the field of view for:

- Dim lightning signal level of 2.51x1013 photons/m2/sr. This photon energy density is equal to 6.4 µJ/m2/sr.

- Background of 0 photons/s/m2/sr/µm.

Rationale: These SNR values are needed to detect radiance associated with lightning under daytime and nighttime conditions. Driver is daytime. Need nighttime prediction. Impulse for lightning signal is less than 1 msec. Lightning line spectra is integrated in the spectral dimension. Background is a continuum.

3.2.1.8 Saturation

The LMX shall not saturate any detector element with a radiance (from Reference Document 4) of:

- Bright background of 1.78x1021 photons/s/m2/sr/µm. This photon radiance is equal to 1.21 times the radiance of a Lambertian reflector.

Rationale: This radiance value encompasses a background radiance of 1.1 times the radiance of a

Lambertian reflector and includes 90-percentile of all lightning event energy densities. Earth scene signals need to be observed without saturation. Extreme Lightning cases outside of the radiance above is rare and might generate rare saturation events.

3.2.1.9 Ringing from a Sharp Edge

The LMX shall not overshoot the top of an edge or undershoot the bottom of scene edges by more than

5% (TBR) of the height of the edge where:

a) The height and the overshoot/undershoot are measured in radiance units.

b) The edge delineates a 10% albedo region from a 90% albedo.

c) The overshoot is averaged over all resampling phases of the detector sample grid to fixed-grid and edge position to detector sample grid.

Rationale: Requirement limits ringing response or overshoot near a sharp edge in scene.

3.2.1.10 Spatial Resolution

The LMX shall have a ground sample resolution of 112 urad.

Rationale: 112 urad is 4 km ground sample distance at nadir.

3.2.2 Event Navigation

All event navigation requirements listed herein apply to optical lightning events and refer to location error of the fixed-grid pixels. The requirements apply to the end-to-end system, taking all instrument, spacecraft, and ground processing effects into account. Unless otherwise specified, all navigation requirements in this document are specified as North/South and East/West angles, in microradians, 3-sigma, and refer to all hours of operation as defined by the operational zones.

In the context of LMX, 3-sigma error is defined to be equal to the 99.73rd percentile of the absolute values of all navigation error observations collected over each 24-hour period from local noon to local noon. When navigation requirements are temporarily suspended, due to Sun/Earth geometry or maneuver outages (including recovery time), the raw errors during the requirements suspension period should be ignored.

3.2.2.1 Navigation Performance Requirements

The LMX shall navigate each optical lightning event.

The LMX navigation error shall not exceed 42 urad (TBR), 3-sigma, per axis, except during eclipse periods.

The LMX navigation error shall not exceed 63 urad (TBR), 3-sigma, per axis, for up to a four hour period

(TBR) that includes partial and/or total eclipse of the sun during eclipse periods. The phasing of the four hour relaxation relative to the eclipse may be design-specific.

Rationale: Navigation error is allocated as portion of pixel size.

3.2.2.2 Star Sensing

If autonomous star sensing is required to meet navigation requirements, the LMX shall have an on-board star catalog provided by the LMX vendor, which is loadable and modifiable from the ground and covers a span of two weeks.

Rationale: If employed, star sensing will require a star catalog and not rely on operators.

3.2.2.3 Quantization Step Size

The quantizing step size for all detector samples shall be less than half the detector noise.

Rationale: Signal quantization by the analog to digital converter should not be the driver in the noise budget in order to avoid having discrete jumps in signal level that can lead to digital artifacts (blocky) data.

3.2.2.4 Lossless Data Compression

If compression is employed, lossless data compression shall be in accordance with Applicable Document

3.3 Design Requirements

3.3.1 Reliability

The LMX shall demonstrate by analysis a Reliability (R) of at least 0.6 after 10 years of on-orbit operations, preceded by up to 5 years of ground storage and up to 5 years of on-orbit storage.

Rationale: Reliability of 0.6 at 10 years is equivalent of MMD of 8.4 years.

The LMX shall demonstrate by analysis a Mean Mission Duration (MMD) of 8.4 years for a design life of

10 years.

No credible single-point failure in the LMX instrument electronics unit or power supply shall permanently preclude the LMX from supporting the mission.

Single string and selectively redundant design approaches may be used outside of electronics unit and power supply design.

The LMX shall have redundancy to eliminate all credible single-point failures in motor windings, heaters and temperature sensors.

The LMX redundant components shall be selectable by external command only.

The LMX units of any Flight Model shall be interchangeable, without modification, with the equivalent units of any other Flight Model.

The LMX shall withstand without damage the sudden removal of operational power.

3.3.2 Mechanical Requirements

Each LMX unit structure shall possess sufficient strength, rigidity and other characteristics required to survive the critical loading conditions that exist within the envelope of handling and mission requirements.

3.3.2.1 Design Limit Loads

The structure shall be capable of withstanding all limit loads without loss of any required function.

Limit loads are defined as all worst case load conditions including temperature effects from the environments expected during all phases of the structure's service life including manufacturing, ground handling, transportation, environmental testing, integration, pre-launch, launch and on-orbit operations and storage.

3.3.2.2 Nonlinear Loads

The structures shall be capable of withstanding redistribution of internal and external loads resulting from nonlinear effects including deflections under load.

3.3.2.3 Yield Strength

The structures shall be able to support yield loads without detrimental permanent deformation. Yield loads are limit loads multiplied by the appropriate protoflight yield factor of safety specified in NASA-

STD-5001B. For structural elements containing beryllium or beryllium alloys, the prototype yield factor of safety is 1.4.

While subjected to any operational load up to yield operational loads, the resulting deformation shall not interfere with the operation of the flight units. Operational load is defined as the expected on-orbit loads while the instrument is operating.

3.3.2.4 Ultimate Strength

The structures shall be able to support ultimate loads without fracture or collapse for at least 3 seconds including ultimate deflections and ultimate deformations of the flight unit structures and their boundaries. However, when proof of strength is shown by dynamic tests simulating actual load conditions, the 3-second limit does not apply. Ultimate loads are limit loads multiplied by the appropriate protoflight ultimate factor of safety specified in NASA-STD-5001B. For structural elements containing beryllium or beryllium alloys, the prototype ultimate factor of safety is 1.6.

3.3.2.5 Structural Stiffness

Stiffness of the structures and their attachments shall be designed by consideration of their performance requirements and their handling, transportation and launch environments.

Special stowage provisions shall be used if required to prevent excessive dynamic amplification during handling, transportation and transient flight events.

3.3.2.6 Unit Stiffness

The fundamental resonant frequency of the sensor unit shall be 50 Hz or greater when the sensor unit is rigidly constrained at its spacecraft interface and the sensor unit is in its launch configuration. The fundamental resonant frequency is defined as the lowest mode with more than 2% effective modal mass in any direction.

The fundamental resonant frequency of the electronics units shall be 50 Hz or greater when the electronics units are rigidly constrained at their spacecraft interfaces. The fundamental resonant frequency is defined as the lowest mode with more than 2% effective modal mass in any direction.

The instrument units shall survive the spacecraft system level testing with notching of interface forces to design limits only.

3.3.2.7 Material Properties

Material properties shall be based on sufficient tests of the material meeting approved specifications to establish design values on a statistical basis.

Design values shall account for the probability of structural failures and loss of any required function due to material variability.

3.3.2.8 Critical Members Design Values

For critical members, design values shall be selected to assure strength with a minimum of 99 percent probability and 95 percent confidence. Structural members are classified as critical when their failure would result in loss of structural integrity of the flight units.

3.3.2.9 Redundant Members Design Values

For redundant members, design values shall be selected to assure strength with a minimum of 90 percent probability and 95 percent confidence. Structural members are classified as redundant when their failure would result in the redistribution of applied loads to other structural members without loss of structural integrity.

3.3.2.10 Selective Design Values

As an exception to Critical Members Design Values and Redundant Members Design Values, greater design values may be used if a representative portion of the material used in the structural member is tested before use to determine that the actual strength properties of that particular structural member will equal or exceed those used in the design.

3.3.2.11 Structural Reliability

Accounting for the presence of stress concentrations and the growth of undetectable flaws, the instrument structures shall withstand loads equivalent to four complete service lifetimes.

While subjected to any flight operational load up to limit flight operational loads, the resulting deformation of the residual structures shall not interfere with the operation of the instrument units.

After any load up to limit loads, the resulting permanent deformation of the residual instrument flight unit structures shall not interfere with the operation of the instrument units.

3.3.2.12 Mechanisms

Deployment, sensor, pointing, drive, separation mechanisms and other moving mechanical assemblies may be designed using MIL-A-83577B and NASA TP-1999-206988.

All mechanisms shall meet performance requirements while operating in an earth gravity environment with any orientation of the gravity vector.

For the on orbit operational conditions, moving mechanical assemblies shall have torque and force ratios per section 2.4.5.3 of GEV-SE using a NASA approved classification of each instrument mechanism.

For all operating points of the actuators, all rotational actuators shall have available a continuous maximum torque output greater than 7.0 milli-Newton meters.

For all operating points of the actuators, all linear actuators shall have available a continuous maximum force output greater than 0.28 N.

For mechanisms using closed-loop control, gain and phase margins shall be greater than 12 dB, and greater than 40 degrees, respectively including the effects of the dynamic properties of any flexible structure.

All mechanisms requiring restraint during launch shall be caged during launch without requiring power to maintain the caged condition.

All mechanisms requiring restraint shall be released from a caged condition by command.

All mechanisms requiring restraint shall be returned to a caged condition ready for launch by either command or by manual actuation of an accessible caging device.

3.3.2.13 Pressurized Units

Pressurized systems shall follow the requirements in accordance with NASA-STD-8719.24 for the design of pressurized systems.

The LMX shall have no open fluid reservoirs when delivered to the spacecraft contractor.

3.3.2.14 Alignment Reference

The LMX shall have a flight worthy cover for the optical alignment cube.

The sensor unit shall have fiduciary marks locating the X, Y, and Z axes of the unit.

3.3.3 Thermal Requirements

3.3.3.1 Temperature Limits

The LMX shall maintain thermally independent units and their internal components within MAT limits, maintaining at least 5 K of analytical/test uncertainty in the MAT range, during all flight operational conditions including bounding worst-case environments.

3.3.3.2 Non Operational Temperature

The Non-Operational Temperatures (NOT) range shall extend at least 20 K warmer than the hot MAT and at least 20 K colder than the cold MAT.

The cold NOT shall be 248 K or colder.

3.3.3.3 Thermal Control Hardware

There shall be two or more serial and independent controls for disabling any heater where any failed on condition would cause over-temperature conditions or exceed the instrument power budget.

The LMX heaters shall be sized to have 25% margin for worst case conditions.

The LMX survival heaters shall be thermostatically controlled.

3.3.4 Onboard Processors Requirements

3.3.4.1 Flight Load Non-Volatile Memory

The entire flight software image shall be contained in non-volatile memory at launch.

3.3.4.2 Commandable Reinitialization

The On-board Processor shall provide for reset by command.

3.3.4.3 Deterministic Power-on Configuration

The On-Board Processor shall initialize upon power-up into a predetermined configuration.

3.3.4.4 Fail-safe Recovery Mode

The Instrument shall provide a fail-safe recovery mode dependent on a minimal hardware configuration capable of accepting and processing a minimal command subset sufficient to load and dump memory.

3.3.5 Flight Software Requirements

3.3.5.1 Language and Methodology

All software developed for the instrument shall be developed with ANSI/ISO standard languages and a widely-accepted, industry-standard, formal software design methodology. Minimal use of processor-specific assembly language is permitted for certain low-level programs such as interrupt service routines and device drivers with NASA approval.

3.3.5.2 Flight Software Upload

Instrument configuration data (e.g. Table Loads or Configuration Parameters) shall be reprogrammable on-orbit without computer restart.

Modified instrument configuration data (e.g. Table Loads or Configuration Parameters) shall be committed to operational use by command.

The flight software shall be capable of being uploaded in Computer Software Configuration Items (CSCIs) without disturbing normal operations and data processing.

The modified flight software shall be available and ready to accept commands within 5 minutes of initiation of a computer restart.

3.3.5.3 Flexibility and Ease of Software Modification

The flight software shall be deterministic in terms of scheduling and prioritization of critical processing tasks to ensure their timely completion.

All software data that are modifiable and examinable by ground operators shall be organized into tables that can be referenced by table number so table data can be loaded and dumped by the ground without reference to memory address.

The definition of instrument commands within the ground database shall not be dependent on physical memory addresses within the flight software.

3.3.5.4 Version Identifiers

All software and firmware versions shall be implemented with an internal identifier (embedded in the executive program) that can be included in the instrument engineering data.

This software identifier shall be keyed to the configuration management process.

3.3.5.5 Flight Processor Resource Sizing

During development, flight processors providing computing resources for instrument subsystems shall be sized for worst case utilization not to exceed the capacity shown below (measured as a percentage of total available resource capacity):

Flight Processor Resource Utilization Limits

S/W PDR S/W CDR S/W AR

RAM Memory 40% 50% 60%

ROM Memory 50% 60% 70%

CPU 40% 50% 60%

3.3.5.6 Software Event Logging

The flight software shall include time-tagged event logging in telemetry.

The event messages shall include all anomalous events, mode transitions, and system performance events.

All flight software components shall utilize a common format for event messages.

The flight software shall provide a means for command to enable and disable queuing of individual event messages.

The flight software shall buffer a minimum of 1000 event messages while the event messages are queued for telemetering to the ground.

The event message queue shall be configurable by command to either (a) discard the new events, or (b) overwrite oldest events when the queue is full.

The flight software shall maintain counters for:

a) The total number of event messages generated

b) The number of event messages discarded because of queue overflow

c) The number of event messages not queued due to being disabled

3.3.5.7 Warm Restart

The flight software shall provide a restart by command with preservation of the event message queue and memory tables.

3.3.5.8 Memory Tests

The flight software shall provide a mechanism to verify the contents of all memory areas.

3.3.5.9 Memory Dump

The flight software, and associated on-board computer hardware, shall provide the capability to dump any location and any size of on-board memory to the ground upon command.

The flight software memory dump capability shall not disturb normal operations and instrument data processing.

3.3.5.10 Telemetry

Telemetry points sampled by the instrument shall be controlled by an on-orbit modifiable table.

The sample rate of every instrument telemetry point shall be controlled by an on-orbit modifiable table.

3.3.6 Power Requirements

3.3.6.1 Power Regulators and Supplies

The power regulators and power supplies shall operate with a phase margin of greater than 45 degrees over the on-orbit operational load, on-orbit operational temperature range, and on-orbit operational input voltage.

The power regulators and power supplies shall operate with a gain margin of greater than 12dB over the on-orbit operational load, on-orbit operational temperature range, and on-orbit operational input voltage.

3.3.6.2 Fuses

The LMX shall not contain fuses.

3.3.6.3 Test Connectors

The LMX shall have flight qualified covers for all test point connectors.

3.3.7 Magnetic Properties

The change in the magnetic field produced by each of the LMX units shall be less than 40 nanoTesla, peak-to-peak, for all operating modes, within a low pass bandwidth of 20 Hz, when measured at a distance of 1 meter from each face of a unit.

3.3.8 (Reserved)

3.3.9 Ground Support Equipment and Development Facilities

3.3.9.1 Electrical System Test Equipment

The Electrical System Test Equipment (ESTE) shall operate the instrument and ground support equipment during performance verification and calibration testing.

The ESTE shall simulate the spacecraft interface with power, clock pulses, command, and telemetry functions.

The ESTE shall include all test equipment necessary to operate and control the instrument in all phases of operation and test modes.

The ESTE shall generate and maintain command logs.

The ESTE shall limit check all health and safety data.

The ESTE shall capture and archive all raw data.

The ESTE shall provide near-real time and off line data analysis of all data necessary to determine the performance characteristics of the instrument.

The ESTE shall interface with the Spacecraft Ground Support Equipment at the Spacecraft Contractor’s facility to extract science and engineering data.

The ESTE shall prohibit hazardous or critical commands being sent to the instrument without operator verification.

3.3.9.2 Flight Software Development Environment

The Flight Software Development Environment (FSDE) shall consist of the hardware and software systems used for realtime, closed loop testing on flight like hardware to develop, test, validate, and demonstrate the flight software is ready for Government acceptance.

The FSDE shall support all lifecycle activities (development, test, and validation) simultaneously.

The FSDE shall contain all items (software, databases, compilers, debuggers, etc.) needed to prepare flight software for the target processor.

The FSDE shall contain engineering (hardware) models of necessary flight hardware as well as dynamic software models comprising the remainder of the instrument and the necessary on-orbit environment.

3.3.9.3 Shipping Container

The shipping container shall be compatible with shipment by air or air-ride van.

The shipping container shall meet all environmental requirements imposed on instrument units consistent with storage and shipping environment.

The shipping container shall have internal temperature, humidity, and pressure monitors with external indicators.

The shipping container shall have shock recorders.

The shipping container shall meet all contamination control requirements imposed on the instrument units.

The shipping container shall be painted white and stenciled to indicate NASA property, content, and structural certification.

GSE shipping containers shall be compatible with shipment by air or air-ride van.

The GSE shipping containers shall be painted white and stenciled to indicate NASA property, content, and structural certification.

3.3.9.4 Instrument Emulator

The instrument emulator will be used to:

a) Validate command procedures including:

1) Normal Operational Command Procedures

2) Contingency Operational Command Procedures

3) Memory uploads (Software Images, tables, etc.).

b) Train operational personnel for normal and contingency operations

c) Provide initial check out of the spacecraft command and telemetry interface

The emulator shall model the capabilities of the memory, cards, and motor drivers so that emulator will accurately simulate all instrument modes and mode transitions.

The emulator shall simulate predefined, scripted anomalies.

The emulator shall simulate failures that are detected by the instrument controller software.

The emulator shall override any telemetry point that is not generated by the Flight Software, to either a static value or to ramp the value over time.

The emulator shall communicate with a spacecraft emulator for instrument command, telemetry, and science packets using Space Wire.

The emulator shall generate predefined science data streams that reflect the size and rate of the actual science data.

The emulator shall use commercial power.

The emulator shall execute instrument flight code.

The emulator shall run in pseudo real time.

The emulator shall accept simulation control commands from a standalone console.

The emulator shall accept simulation control commands from the spacecraft emulator.

The emulator shall generate housekeeping, engineering, and diagnostic telemetry data reflective of commanded mode and imaging pattern.

The emulator shall accept real-time inputs to change simulated telemetry or modeling parameters.

The emulator shall maintain a log of all simulation directives received.

The emulator shall implement a scheme to allow the user to update the default configuration information nominally stored in EEPROM.

4 Design Verification Requirements The following requirements represents only a portion of the overall system verification (i.e., contractor derived requirements are not described) that must be integrated into the total system program which verifies that the system will meet the mission requirements. A system performance verification program documenting the overall verification plan, implementation, and results is required which will provide traceability from mission specification requirements to launch and initial on-orbit capability.

This will also provide the baseline for tracking on-orbit performance versus pre-launch capability.

4.1 Performance Operating Time and Trouble-Free Performance Testing A minimum of one-thousand (1000) hours of operating/powered-on time shall be accumulated on all flight electronic hardware and spares, prior to shipping the instrument. Note: For electronics consisting of a Primary and Redundant (that is, A and B sides), 1000 hours shall be accumulated on each side.

At the conclusion of the performance verification program, the instrument shall have demonstrated trouble-free performance testing for at least the last 350 hours of operation prior to instrument shipment.

Trouble-free operation shall include 200 hours during the thermal-vacuum test with 100 hours being logged at the hot-dwell temperature and 100 hours being logged at the cold-dwell temperature.

4.2 Structural and Mechanical Verification Requirements

4.2.1 Mechanical Test Factors and Duration

The OCX contractor shall employ the mechanical test factors and durations in accordance with

Section 2.2.4 of GSFC-STD-7000. For pressurized glass elements, the qualification test factor is

2.0, and the acceptance test factor is 1.25.

4.2.2 Minimum Workmanship

All electrical, electronic, and electro-mechanical components shall be subjected to minimum workmanship test levels as specified in GSFC-STD-7000 Section 2.4.2.6.

4.2.3 Testing in Flight Configuration

Hardware powered on for launch shall be powered on for testing.

4.2.4 Structural Proof Testing

Primary and secondary structures fabricated from nonmetallic composites, beryllium, or containing bonded joints or bonded inserts shall be proof tested in accordance with GSFC-STD-

7000 Section 2.4.1.4.1.

4.2.5 Modal Survey Characterization

Modes up to 75 Hz and with more than 5% predicted modal mass participation shall have frequencies verified by test.

Predicted frequencies of these modes shall correlate to test frequencies within 5%. (CCR 00218)

Modes below 50 Hz and with more than 5% predicted modal mass participation shall be verified by modal survey.

Cross-orthogonality checks of these test and analytical mode shapes, with respect to the analytical mass matrix, shall be performed with the requirement of obtaining at least 0.9 on diagonal terms and no greater than 0.1 off-diagonal.

The LMX contractor shall determine by loads and jitter analysis the critical modal parameters.

The LMX contractor shall measure by test the critical modal parameters of the structure.

The measured modal parameters shall be used to verify and update the loads and jitter performance.

4.2.6 Structural Qualification

Structural tests that demonstrate that flight hardware is compatible with expected mission environments shall be conducted in compliance with GSFC-STD-7000 Section 2.4.

Any glass elements with bonds shall be qualified with a non-flight prototype.

The number of qualification tests on a non-flight prototype shall be greater than or equal to the planned number of acceptance tests performed on any flight unit.

The test durations shall have a tolerance of plus 5 seconds and minus zero.

The qualification tests shall reduce the input levels as necessary to prevent the unit interface forces from exceeding the yield limits defined in the instrument ICD.

The acceptance tests shall reduce the input levels as necessary to prevent the interface forces from exceeding the flight limits defined in the instrument ICD.

Vibration tests shall be performed to provide test data sufficient to update structural models, to compute responses to launch loads using updated models, and to verify margins against yield and ultimate strength requirements in the 50.1 to 100 Hz frequency range.

For shock isolated units, the lower frequency limit of the input shock spectrum shall be less than

0.7 times the frequency of the first natural mode of the isolated unit.

4.2.7 Deployment and Articulation Verification

All flight deployables, movable appendages, and mechanisms shall demonstrate full range of motion and articulation under worst-case and flight-like conditions (including blankets) prior to flight.

4.2.8 Life Test

Except for active cryogenic cooling systems, a life test shall be conducted, within representative operational environments, to at least 2x expected life for all repetitive motion devices with a goal of completing 1x expected life by CDR.

For active cryogenic cooling systems, the total operating time or number of operational cycles without failure shall be at least 1.0 times mission life with 0.5 times mission life completed prior to the scheduled launch date of the first flight model.

4.2.9 Mechanical Clearance Verification

Ver…