This is the WIRE system requirements document. It is a hyper-text document detailing all system level requirements for the WIRE spacecraft, launch vehicle, and ground system. All requirements in this document are based on the mission requirements and the system concept.
This page of the system requirements document is the description of the system and a listing of the requirements, as well as the applicability of each requirement. It contains links to every requirement, but it does not contain the requirements themselves. Each requirement link is highlighted (underlined). The listed requirements which are not highlighted are TBD at this time.
The word "shall" is used for all requirements. If it doesn't say "shall", it is not a requirement. If it does say "shall", it is a requirement.
DEF.0 Definitions CON.0 System Concept SVY.0 The Survey SYS.0 System Requirements SAF.0 Safety CNTA.0 Contamination VER.0 Environmental Verification INS.0 Instrument MECH.0 Mechanical MECH.DESC.0 Description MECH.REQ.0 Requirements MECH.REQ.GEN.0 General MECH.REQ.SA.0 Solar Array MECH.REQ.MNT.0 Mounting ACS.0 Attitude Control System ACS.DESC.0 Description ACS.DESC.1 Analog Acquisition ACS.DESC.2 ACE safehold ACS.DESC.3 SCS safehold ACS.DESC.4 Zenith sunpoint ACS.DESC.5 Transitional Stellar ACS.DESC.6 Normal mode ACS.REQ.0 Requirements CDH.0 Command and Data Handling CDH.DESC.0 Description CDH.DESC.1 Processor CDH.DESC.2 Up/Down Card CDH.DESC.3 I/O Card CDH.DESC.4 Memory Card CDH.DESC.5 Low Voltage Power Converter CDH.DESC.6 Backplane CDH.DESC.7 Spacecraft Autonomy CDH.DESC.8 Watchdogs CDH.DESC.9 Deployment Timers CDH.DESC.10 Error Detection and Correction CDH.DESC.11 Software CDH.REQ.0 Requirements CDH.REQ.GEN.0 General CDH.REQ.INS.0 Instrument Servicing PWR.0 Power RF.0 RF System THERM.0 Thermal System THERM.DESC.0 Description THERM.DESC.1 Structure/Radiators THERM.DESC.2 Solar Arrays THERM.DESC.3 Battery THERM.DESC.4 Star Tracker THERM.DESC.5 Wire Instrument THERM.DESC.6 Heater System THERM.DESC.7 Temperature Monitoring THERM.REQ.0 Requirements HAR.0 Harness GSE.0 Ground Support Equipment VEH.0 Launch System GND.0 Ground System REV Revision
ATS
byte
captive carry
component
cryostat's emergency vent
instrument
kbyte
primary battery
real-time command
RTS
safehold
secondary battery
spacecraft
spacecraft bus
stored command
The WIRE mission is described in the WIRE home page. The mission requirements are contained in the Mission Requirements Document. The top-level science requirements are described in the Science and Instrument Functional Requirements document. The spacecraft will be as similar to SWAS as possible with the WIRE instrument substituded for the SWAS instrument. The launch vehicle will be a Pegasus XL. The ground system will be based in the SMEX Payload Operations Control Center.
The WIRE survey will cover over 100 square degrees of sky and detect sources 200-500 fainter than the IRAS Faint Source Catalog at 25 um and 500-2000 times fainter at 12 um. The resulting catalog, expected to contain at least 30,000 starburst galaxies, will reveal their evolutionary history out to redshifts of 0.5 - 1 and the evolutionary history of extremely luminous galaxies beyond redshifts of 5. This will be the first significant galaxy survey to probe these redshifts at far-infrared wavelengths where extinction effects are small and where most of the bolometric luminosity of starburst galaxies, and possibly of the Universe, can be measured.
The survey will consist of repeated stare-mode observations at high Galactic latitudes. Each orbit will consist of 5 to 10 observing segments with each segment lasting approximately 10 minutes. Up to four of these segments would consist of primary science target observations. The observations during a primary science segment will consist of repeated, short (1-2 minutes) exposures of the same field, each separated by a small positional offset, or "dither". Observations of a science field from one or more orbits will be background subtracted, flat-fielded, registered, and coadded on the ground to produce final images that will contain the detections of the distant starburst galaxies. Since the purpose is to observe extragalactic sources, most of the primary science fields will be chosen well away from the Galactic plane, so that source confusion and extended emission do not limit the survey.
Because of a requirement to not look in the ram direction early in the mission, each orbit may consist of up to 12 observing segments (currently limited by the daily uplink volume allowed).
back to Table of Contents
The following requirements apply to the entire system:
SYS.REQ.1 Mission lifetime
SYS.REQ.2 Orbit
SYS.REQ.3 Orbital Debris
SYS.REQ.4 Sky Availability
SYS.REQ.5 Mass allocations
SYS.REQ.6 Power allocations
SYS.REQ.7 Temperatures
SYS.REQ.8 Bus voltage
SYS.REQ.9 In-rush current
SYS.REQ.10 Radiation
SYS.REQ.11 Materials usage
SYS.REQ.12 Launch vehicle orientation
SYS.REQ.13 Coordinate system
SYS.REQ.14 In-orbit check-out period
SYS.REQ.15 Command ingest rate
SYS.REQ.16 Passes per day
Even though Pegasus is the baseline launch vehicle, the spacecraft design should also accomodate the Lockeed Launch Vehicle, Cosmos, Taurus, and Delta.
back to Table of Contents
SAF.DESC.0 DESCRIPTION
Due to the hydrogen in the instrument, safety will be less straightforward than with previous Small Explorer missions.
SAF.REQ.0 REQUIREMENTS
System safety shall be based on GSFC S-740-89-978, System Safety Implementation Plan for the Small Explorer (SMEX) Spacecraft, dated August 1990. With regard to WIRE, the current version of Western Range safety regulations shall be used per Eastern and Western Range 127-1, March 1995. WIRE shall comply to programmatic and technical requirements of EWR 127-1. Because Pegasus is the launch vehicle, WIRE shall comply with safety considerations per OSC SSD-TD-0005, Pegasus Design Safety Requirements Document, and OSC SSD-TD-0018, Pegasus Requirements Document for Ground Operations.
In addition to the above documents, the following requirements are imposed on the system:
SAF.REQ.1 Last pyro bridge-wire check
SAF.REQ.2 Critical commands
back to Table of Contents
CNTA.DESC.0 DESCRIPTION
The performance of the WIRE instrument and supporting subsystems are subject to degradation from excessive contamination on sensitive components. Contaminants can obscure optical surfaces, diminish detector sensitivity, and increase thermal control coating absorptance. The WIRE contamination control program is designed to limit such degradation by defining allowable spacecraft surface contamination, outgassing levels, and outgassing paths. These allowances are then used to establish requirements for materials selection, materials processing, and maintenance of flight hardware surface cleanliness during ground operations.
CNTA.REQ.0 REQUIREMENTS
Specific WIRE contamination allowances and requirements are defined in the WIRE Contamination Requirements and Control Plan, WIRE-SPEC-006.
CNTA.WHO.0 CONTACTS
The Contamination engineer is Mike Rodriquez.
phone: (301) 286-0565
E-mail: michael.r.rodriguez.1@gsfc.nasa.gov
back to Table of Contents
VER.DESC.0 DESCRIPTION
The WIRE spacecraft, subsystems, and components must be verified in accordance with the established environmental verification requirements for Goddard Space Flight Center (GSFC) as described in the General Environmental Verification Specification for Space Transportation System (STS) and Expendable Launch Vehicle (ELV) Payloads, Subsystems, and Components (GEVS-SE). Environmental verification assures the spacecraft, subsystems, and components are capable of withstanding the ground, transportation, launch, and on orbit environments for the required mission duration.
Verification of the environmental requirements shall be accomplished by test, demonstration, analysis, or a combination thereof. Specific environmental activities required for each level of assembly is defined in the WIRE Verification Matrix. WIRE hardware will be classified as protoflight and therefore require qualification level testing for acceptance duration.
VER.REQ.0 REQUIREMENTS
VER.REQ.1 Spacecraft comprehensive test
VER.REQ.2 Spacecraft functional
VER.REQ.3 Daily trending test
VER.REQ.4 Modal Survey
VER.REQ.5 Random Vibration
VER.REQ.6 Loads
VER.REQ.7 Shock
VER.REQ.8 Acoustic
VER.REQ.9 Mass Properties
VER.REQ.10 Pressure Profile
VER.REQ.11 Electromagnetic Interference
VER.REQ.12 Electromagnetic Compatibility
VER.REQ.13 Magnetic
VER.REQ.14 Thermal Vacuum/ Thermal Balance/ Thermal Cycling
VER.REQ.15 Life Test
VER.REQ.16 Mechanical Function
VER.REQ.17 Bakeout
VER.REQ.18 Leak
VER.ICD.0 INTERFACES
VER.WHO.0 CONTACTS
The Verification Engineer is Pete Mule.
phone: (301) 286-8281
E-mail: PETER_MULE@ccmail.gsfc.nasa.gov
back to Table of Contents
INS.DESC.0 DESCRIPTION
The WIRE Instrument is a cryogenically cooled, infrared telescope designed to conduct a sky survey of high-redshift starburst galaxies 500 times fainter than the existing baseline which was gathered by the Infrared Astronomy Satellite (IRAS) and documented in the IRAS Faint Source Survey Catalog.
The telescope is a Ritchey-Chretien Cassegrain design with a 30 cm aperture/primary mirror diameter having a 33 x 33 arcminute field of view. The primary and secondary mirrors are diamond turned aluminum. An optical band-pass filter and dichroic beam splitter separates the focused infrared energy for viewing in two color bands (12 and 25 micrometers wavelengths). The infrared image is then captured by two 128 x 128 pixel, Si:As BIB detector arrays fabricated by Rockwell International.
To keep the design simple and control costs, there are no moving parts in the WIRE instrument. The entire optical assembly is an integral, independent module which plugs into the cryostat. The cryostat is a two stage, solid hydrogen design fabricated by Lockheed Martin Advanced Technology Center. It will cool the detector arrays to 7.5 K and the optics to about 12 K.
The Utah State University's Space Dynamic Laboratory will fabricate the telescope optical components and integrate them with the cryostat.
INS.REQ.0 REQUIREMENTS
INS.REQ.GEN.0 General Requirements
INS.REQ.GEN.1 Emergency Vent
INS.REQ.GEN.2 Ice Formation
INS.REQ.GEN.3 Fill Orientation
INS.REQ.GEN.4 Instrument Hold Time
INS.REQ.GEN.5 Time to orbit vent opening
INS.REQ.GEN.6 Pyro Firing Circuits
INS.REQ.GEN.7 Vent opening energy consumption
INS.REQ.GEN.8 Maximum hydrogen venting torques
INS.REQ.GEN.9 Maximum cover ejection momentum
INS.REQ.OPS.0 Timeline Generation and Target Selection
The following requirements apply to timeline generation and target selection:
INS.REQ.OPS.1 Moon avoidance
INS.REQ.OPS.2 Star selection
INS.REQ.OPS.3 12 hour command volume
INS.REQ.OPS.4 Star tracker misalignment compensation
INS.REQ.ANAL.0 Data Processing
The following requirements apply to instrument data processing:
INS.REQ.ANAL.1 Position reconstruction
INS.ICD.0 INTERFACES
Spacecraft computer
Power Distribution
Spacecraft structure
Launch vehicle
INS.WHO.0 CONTACTS
The principal investigator is Dr. Perry Hacking.
phone: (818) 397-9525
E-mail: perry@ipac.caltech.edu
The project manager at JPL is Helene Schember.
phone: (818)354-2012
E-mail: helene@squid.jpl.nasa.gov
The instrument engineer at Goddard is Leroy Sparr.
phone: (301) 286-3811
E-mail: leroy.sparr@gsfc.nasa.gov
back to Table of Contents
The main objective in the design of the WIRE S/C structure is to minimize mass. Therefore an all fiber reinforced composite type structure has been chosen as the baseline for the WIRE Mechanical/Structural concept, to help alleviate this problem.
The baseline structural concept for the WIRE S/C is an equilateral eight sided semi-cylindrical structure. The structure will incorporate three (3) decks. An aft deck, which will interface to the launch vehicle. A mid deck, which will support misc. components. A forward deck, which will support the instrument interface. A truss type structure (i.e. straight longerons) will span and support all three decks. Eight (8) equipment panels and eight (8) access panels will close out the structure and carry the shear loads through the structure. The equipment panels will support the major S/C components (i.e. Electronics boxes). A significant number of equipment panels must also double as thermal radiators to dump heat from the high power components of the S/C. The S/C components will be mounted to the inside of the equipment panels such that they will all be facing internally to the structure when the S/C is fully assembled.
The WIRE instrument is to be mounted on the forward end of the S/C bus structure. There are thirteen major components and/or Electronic boxes mounted internally to the S/C structure:
1) WIRE Instrument Electonics (WIE)
2) Spacecraft Computer System (SCS)
3) Attitude Control Electronics (ACE)
4) Gyro Assembly
5) Transponder
6) Battery
7) Spacecraft Power Electronics (SPE)
8) Reaction Wheels (4 required)
9) Shunt Driver Box
10) Magnetic Torquer Rods
11) 1553 Bus Couplers
12) Digital Sun Sensor Electronics
13) Earth Sensor Electronics
Additionally, the following must be mounted externally on the spacecraft structure:
1) Magnetometer head
2) Digital Sun Sensor head
3) Coarse Sun Sensor heads (six)
4) Star tracker
5) Earth sensor heads (two)
6) Communication Antennas
7) Test Connector Panel
The structure must also accomodate the harnessing between the boxes.
The high heat generating boxes are to be placed on the anti-sun side of the S/C, to minimize the thermal load on the S/C and instrument.
The WIRE Instrument is a solid Hydrogen Cryostat/Dewar. The cryostat incorporates four distinct mounting pads for mounting to the S/C. The mounting pads are located on the lower end of the cryostat. A strut/truss type structure will be designed to span between the four interface pads (i.e. hard points) on the cryostat shell to the forward deck on the S/C structure. The conductive heat path between the S/C and the instrument is to be minimized. Therefore the material for the struts is to be selected such that it minimizes the heat load from the S/C to the instrument.
The WIRE S/C is to fit within the PEGASUS-XL payload envelope, which has a static envelope dia. of 44 " (1.12m), height of 83"(2.11m), the upper portion being a curved ogive section. The payload interface is a 38"(0.97m) dia. Aluminum ring with a 60 X 1/4" bolt hole pattern.
MECH.REQ.GEN.0 General Requirements
VER.REQ.6 Design Loads
MECH.REQ.GEN.2 Structure Temperatures
MECH.REQ.GEN.3 Equipment Panel Thermal Conductivity
MECH.REQ.GEN.4 Center-of-pressure/center-of-mass offset
MECH.REQ.GEN.5 Center-of-mass/z-axis offset
MECH.REQ.GEN.6 Instrument to star tracker alignment
MECH.REQ.GEN.7 Gyro to star tracker alignment
MECH.REQ.GEN.8 Instrument to star tracker stability
The following requirements apply to the solar array:
MECH.REQ.SA.1 Area
MECH.REQ.SA.2 Deployment time
MECH.REQ.SA.3 Deployed stiffness
CDH.REQ.GEN.25 Deployment telemetry
MECH.REQ.MNT.0 Mounting Requirements
The following are mounting requirements:
MECH.REQ.MNT.1 Instrument
MECH.REQ.MNT.2 WIRE Instrument Electronics
MECH.REQ.MNT.3 Spacecraft Computer System
MECH.REQ.MNT.4 Attitude Control Electronics (none)
MECH.REQ.MNT.5 Gyro Assembly
MECH.REQ.MNT.6 Transponder
MECH.REQ.MNT.7 Battery
MECH.REQ.MNT.8 Spacecraft Power Electronics
MECH.REQ.MNT.9 Reaction Wheels
MECH.REQ.MNT.10 Shunt Driver Box
MECH.REQ.MNT.11 Electromagnetic torquer bars
MECH.REQ.MNT.12 1553 Bus Couplers
MECH.REQ.MNT.13 Digital Sun Sensor Electronics (none)
MECH.REQ.MNT.14 Earth Sensor Electronics
MECH.REQ.MNT.15 Magnetometer head
MECH.REQ.MNT.16 Digital Sun Sensor head
MECH.REQ.MNT.17 Coarse Sun Sensors
MECH.REQ.MNT.18 Star tracker
MECH.REQ.MNT.19 Communication Antennas
MECH.REQ.MNT.20 Test Connector Panel
MECH.REQ.MNT.21 Earth Sensor Heads
MECH.ICD.0 INTERFACES
Instrument
Launch vehicle
Spacecraft computer system
Bus couplers
Spacecraft power electronics
Transponder
Antenna
Star tracker
Earth sensor
Attitude control electronics
Shunt box
Battery
Solar array
Heaters and thermistors
Test connector panel
MECH.WHO.0 CONTACTS
The mechanical lead is Giulio Rosanova.
phone: (301) 286-5907
E-mail: Giulio.Rosanova@gsfc.nasa.gov
back to Table of Contents
ACS.DESC.0 DESCRIPTION
The attitude control system is similar to the SWAS system which uses the following sensors and actuators: magnetometer, coarse sun sensors, digital sun sensor, gyros, star tracker, torque rods, and reaction wheels. Changes were necessary to meet the new earth avoidance constraint and the tighter sun avoidance constraint of WIRE. A coarse earth sensor was added to provide a reference for earth avoidance control and constraint checking. Several pointing modes were modified to account for this new constraint. Since the large slew maneuvers will be predominately about the y-axis (x- and z-axis rotations will be small), the spacecraft will maintain a momentum bias toward the sun throughout the entire mission. This aides in meeting the sun constraint by providing passive stability about the sunline and allows for the limiting of maneuvers away from the sun.
The attitude control system will have six (TBD) different pointing modes: analog acquisition, ACE safehold, SCS safehold, zenith sunpoint, transitional stellar acquisition, and stellar point. These modes are listed in hierarchical order, with analog safehold being the lowest level. Downward transitions from normal mode are autonomous, protecting the spacecraft from anomalous conditions. Upward transitions are initiated by ground command, allowing the spacecraft operators to verify the safety of the spacecraft before and after the transition. Upward transitions from zenith sunpoint are autonomous, provided a science timeline has been activated by ground command. The different modes allow graceful transitions and a quick return to normal operations.
ACS.DESC.1 Analog Acquisition
Analog acquisition is the default power-up mode used for initial acquisition. After the ACS is commanded to ACE safehold, analog acquisition will only be used if the 8085 processor in the attitude control electronics (ACE) stops running. Analog acquisition is identical to the safehold flying on SAMPEX and SWAS. It performs the same functions as the ACE safehold except for the earth avoidance.
ACS.DESC.2 ACE Safehold
ACE safehold damps body rates, points the solar arrays at the sun, and points the instrument boresight away from the earth. These functions are accomplished with a minimal set of hardware and software. ACE safehold is the safety net which protects the spacecraft from serious anomalies such as software upsets. ACE safehold is the default for all ACE box resets except power-up.
ACS.DESC.3 SCS Safehold
SCS safehold is ACE safehold implemented with the spacecraft processor. It provides a graceful transition from safehold's hardware control to the processor's software control.
ACS.DESC.4 Zenith Sunpoint
Zenith sunpoint uses the sun vector and the magnetic field vector measurements along with a magnetic field model and a solar model to determine the attitude of the spacecraft. It then uses the momentum wheels to point the solar array within TBD (15) degrees of the sun and the instrument boresight toward zenith.
ACS.DESC.5 Transitional Stellar Acquisition
Transitional stellar acquisition (TBD) points the instrument toward one of TBD pre-defined points so that the star tracker can acquire stars. The attitude control system uses the normal mode algorithms for attitude determination and control.
ACS.DESC.6 Stellar Point Mode
Stellar point mode is the science targeting mode in which the spacecraft collects science data.
ACS.REQ.0 REQUIREMENTS
ACS.REQ.ACE.0 ACE Requirements
The following requirements apply to the attitude control electronics:
ACS.REQ.ACE.1 Power reset
ACS.REQ.ALL.0 ACS All Mode Requirements
The following requirements apply to all ACS modes:
ACS.REQ.ALL.1 Instrument venting
ACS.REQ.ACQ.0 Analog Acquisition Mode Requirements
The following requirements apply to Analog Acquisition mode:
ACS.REQ.ACQ.1 Analog Acquisition Mode
ACS.REQ.ACQ.2 Sun Pointing Accuracy
ACS.REQ.ACQ.3 Initial Sun Acquisition
ACS.REQ.ACQ.4 Analog Acquisition Mode Transitions
ACS.REQ.NAC.0 Non-Acquisition-Mode Requirements
The following requirements apply to all ACS modes except analog acquisition:
ACS.REQ.NAC.1 Sun Avoidance Constraint
ACS.REQ.NAC.2 Earth Avoidance Constraint
ACS.REQ.ASF.0 ACE Safehold Requirements
The following requirements apply to ACE safehold:
ACS.REQ.ASF.1 ACE safehold
ACS.REQ.ASF.2 Sun/Zenith Reacquisition
ACS.REQ.ASF.3 No Failure transition to safehold
ACS.REQ.ASF.4 Cover Ejection
ACS.REQ.ASF.5 ACE safehold mode transitions
ACS.REQ.ACQ.2 Sun Pointing Accuracy
ACS.REQ.SSF.0 SCS Safehold Requirements
The following requirements apply to SCS safehold:
ACS.REQ.SSF.1 SCS safehold mode
ACS.REQ.SSF.2 SCS safehold mode transitions
ACS.REQ.ASF.2 Sun/Zenith Reacquisition
ACS.REQ.ASF.3 No Failure transition to safehold
ACS.REQ.ACQ.2 Sun Pointing Accuracy
ACS.REQ.ZEN.0 Zenith Sunpoint Mode Requirements
The following requirements apply to zenith sunpoint:
ACS.REQ.ZEN.1 Zenith sunpoint mode
ACS.REQ.ZEN.2 Sun Pointing Accuracy
ACS.REQ.ZEN.3 Zenith sunpoint mode transitions
ACS.REQ.TSA.0 Transitional Stellar Acquisition Mode Requirements
The following requirements apply to transitional stellar acquisition:
ACS.REQ.TSA.1 Transitional stellar acquisition mode
ACS.REQ.TSA.2 Transitional stellar acquisition mode transitions
ACS.REQ.STP.0 Stellar Point Mode Requirements
The following requirements apply to stellar point (STP) mode when the guide stars meet the ACS star selection requirements (INS.REQ.OPS.2):
ACS.REQ.STP.1 Stellar Point Mode
ACS.REQ.STP.2 Pointing accuracy
ACS.REQ.STP.3 Azimuth accuracy
ACS.REQ.STP.4 Pointing stability
ACS.REQ.STP.5 Slew Time
ACS.REQ.STP.6 Dither
ACS.REQ.STP.7 Stellar Point Mode Transitions
ACS.REQ.FDH.0 Fault Detection and Handling Requirements
The following requirements apply to fault detection and handling:
ACS.REQ.FDH.1 Fault detection and handling
ACS.REQ.FDH.2 Sun/earth constraint checks
ACS.REQ.FDH.3 Y-Wheel Failure
ACS.REQ.FDH.4 Earth Avoidance Sensor Failure
ACS.ICD.0 INTERFACES
ACE box mechanical
ACE to SCS
Power Distribution
Star tracker mechanical
Tracker to ACE
Earth sensor mechanical
Earth sensor to ACE
other sensors and actuators
ACS.WHO.0 CONTACTS
The ACS lead is Todd Campa.
phone: (301) 286-0528
E-mail: Todd.Campa@gsfc.nasa.gov
back to Table of Contents
The Spacecraft Computer System (SCS) is the heart of the WIRE avionics system and contains the required components to receive and decode commands, collect, store and playback several different types of telemetry data. The WIRE data flow is shown in the figure. The SCS telemetry and commanding processes conform to the Consultative Committee for Space Data System (CCSDS) recommendations for packet telemetry and telecommanding. The SCS subsystem collects science data, ACS data, and spacecraft housekeeping data which is stored in the high density memory board for later transmission during a downlink opportunity. It receives ground commands from the Transponder, executes real-time commands or time-tagged command sequences. It also forwards subsystem commands to appropriate subsystems. The telemetry science data can be collected by the SCS via the high speed synchronous serial interface and/or 1553 bus interface. The WIRE science telemetry data is stored in the Bulk Memory for later use. In addition, the SCS telemeters the spacecraft housekeeping data to the spacecraft Integration and Test Ground Support Equipment (I&T GSE) via the Pegasus launch vehicle before payload separation.
The SCS hardware consists of five key components: Processor board, Bulk Memory board, Uplink/Downlink (Up/Down) board, Input/Output (IO) board, and Low Voltage Power Converter (LVPC) board. These components are all contained within the same enclosure. Within this box, there are electrical connections between these SCS key components via the backplane. The following section describes top-level descriptions of these components.
CDH.DESC.1 Processor board
The 80386 microprocessor based circuit board provides the primary processing capability for the SCS. The Processor board is capable of processing the C&DH and ACS processes.
The Processor board uses an Intel 80386DX-20 microprocessor operating at 16MHz. It is supported by the use of Intel's 80387DX math coprocessor and 82380-20 DMA controller. The Processor board contains a 1553B terminal, using UTMC BCRTM protocol integrated circuits with 128 Kbytes of shared RAM. The board has a total of one megabyte of rad-hard static RAM and a total of 576 Kbytes of EEPROM (64 Kbytes of bootstrap PROM, 128 Kbytes of boot PROM and 384 Kbytes of programmable PROM). The Processor board contains a Bus Controller ASIC that is used to control the input/output interface to the backplane.
The Processor board serves as a Bus Controller (BC) of the SCS 1553B-STD-MIL Data Bus network that connects to spacecraft subsystems and instruments. The hardware watchdog timer resets the processor if the flight software fails. A Universal Asynchronous Receiver and Transmitter (UART) channel (RS-232) is available to support flight software loads and software debugging during ground tests. This interface will be disabled for flight operations.
CDH.DESC.2 Uplink/Downlink board
The Up/Down board interfaces to other SCS boards via the backplane bus and to the Transponder via hardlines. The uplink portion interfaces to the Transponder command receiver for receipt of the ground commands. The downlink portion interfaces to the Transponder telemetry transmitter for downlink of the spacecraft housekeeping and science data. The Command and Data Handling (C&DH) flight software routes telemetry data to the Up/Down board via the backplane bus. The Up/Down board supports data rates of 2.25 Mbits/sec, 1.125 Mbits/sec, or 23.44 Kbits/sec. In addition, the downlink telemetry coding is selectable from one of several options (NRZ-L, Convolutional, Bi-Phase-L, or any combination of these codes).
The Up/Down board provides the synchronous high speed serial interface which allows the SCS to receive bursts of science data from the WIRE Instrument. The interface consists of three differential pair signals (clock, data and data ready) that meet the EIA standard RS-422. The data transfer rate is up to 900 Kbits per second. When the SCS receives the science data, it stores the data into the Bulk Memory and can play back the data to the ground at next downlink opportunity.
The Up/Down board also provides a hardware command decoder that decodes a critical ground command and directly distributes the decoded command (pulses) to selected subsystem via hardlines. This command will bypass the command verification of the processor flight software. The critical command will be used when ground commands are not accepted by the Processor board due to the failure of the flight software or hardware.
CDH.DESC.3 Input/Output board
The Input/Output (IO) board interfaces to the Processor board via the backplane bus. It provides for standard Input/Output interfaces between the SCS and other subsystems. It interfaces to several onboard subsystems and receives the housekeeping status and data from the Transponder, subsystem thermistors and the instrument thermistors. The IO board also sends bi-level commands and analog signals to subsystems if required. In addition, the IO board provides the telemetry and command interface between the SCS and the Pegasus launch vehicle for communications link prior to payload separation.
The IO board maintains the Mission Elapsed Time (MET) and a one hertz clock, and distributes them to onboard subsystems. The one hertz clock is used to provide the spacecraft timing synchronization for the processor. The IO board provides the Barker Watchdog Timer, the Hardware Watchdog Timer, and the Command Timer that use the 1 Hz clock as a clock counter. The Barker Code Timer is expired after 28 hours without receiving a ground command. The Hardware Watchdog Timer is used as a backup of the Bus Controller ASIC watchdog Timer if the Processor fails. These two timers will strobe the Processor board power. The Command Timer is programmable up to 90 minutes with one second resolution and used to trigger the Solar Array Deployment functions upon the Pegasus separation occurrence. In addition, it provides the Solar Array deployment interlock that would prevent the premature solar array deployment condition.
The IO board contains a commercially available hybrid DC-to-DC power converter and an EMI Filter. The power converter transforms the spacecraft unregulated +28 V DC power into regulated +15 V DC and -15 V DC. The ± 15 V DC voltages are used to supply power to the analog circuitry ( A/D Converter and Analog Multiplexers).
CDH.DESC.4 Bulk Memory board
The Bulk Memory board provides the SCS with instrument and housekeeping data storage. TRACE and WIRE missions require the SCS to provide 2.4 gigabits of bulk memory to store science images, and an additional 128 Kbytes of EEPROM for expansion of flight software code. To support these new requirements and provide no impacts to the SWAS SCS hardware/software configuration, functional performances, cost and delivery schedule, the SCS contains a new generation of the Bulk Memory board, called Dynamic Random Access Memory (DRAM) Bulk Memory. The DRAM Bulk Memory board consists of an DRAM Controller (ACTEL-1280 FPGA) to control fifteen 160-megabit LCC DRAM modules, and an EEPROM Controller (ACTEL-1020 FPGA) to control four rad-hard 256-Kbit EEPROM chips. The LCC DRAM module developed by Irvine Sensors Corporation in Burlington, Vermont, utilizes rad-hard high density IBM DRAM stacks. The DRAM Bulk Memory board is physically/functionally compatible with the SRAM Bulk Memory board developed for SWAS mission. However, it contains very high density memory and is cost effective. The known bad memory locations can be mapped around by the C&DH flight software.
CDH.DESC.5 Low Voltage Power Converter board
The Low Voltage Power Converter (LVPC) board is used to convert the spacecraft unregulated +28V power into the regulated +5.0 Volts (+5V VCC) and +5 Volts Standby (+5V STBY). The LVPC is actually two pulse-width modulator DC-to-DC converters, the +5V VCC converter and the +5V STBY converter. The switchable +5V VCC powers the processor board; the unswitchable +5V STBY powers the IO, Up/Down, and Bulk Memory boards. The converter operates over the range of +21V to +35V input voltage variation.
CDH.DESC.6 Backplane
The backplane for the SCS system is based on a modified PC-AT 386 backplane design which has been optimized for use in a space environment. The backplane design used for the SCS contains 32 bit address and data buses. An eight check bit bus communicating between the Processor and Bulk Memory boards is added to the backplane to support EDAC requirements. The backplane design supports five circuit boards on the backplane. All transactions between two boards take place on the backplane. The Bus Controller ASIC residing on the 80386 Processor board controls all backplane data transfers by specifying the address and type of transfer (read or write). The backplane provides 7 interrupt levels from external peripheral devices and distributes +5V VCC and +5V STBY to appropriate SCS boards.
CDH.DESC.7 Spacecraft autonomy
The baseline on-orbit WIRE ground contact plan is two downlinks/uplinks per day using Wallops and Poker Flat ground stations. Each contact will last an average of approximately 8 (TBD) minutes. Between the ground contacts, the C&DH flight software hosted by the SCS provides the autonomous operation of the spacecraft by issuing preplanned commands uploaded by the ground into processor stored command memory. The flight software monitors the spacecraft house-keeping data for anomalies and responds to them with appropriate actions. Under worst case conditions, the spacecraft is designed so that it is able to miss the ground contacts for periods of up to 28 hours and will be capable of sustaining itself without disrupting normal operations.
CDH.DESC.8 Watchdog strategy
Based on the SMEX single string design architecture except where safety/reliability concerns require additional protection, the SCS is built with minimal hardware redundancy. The watchdog strategy is implemented on SCS hardware and software with very minimal additional hardware/software. The watchdog strategy will provide levels of protection against processor faults and processor memory anomalies caused by software and/or hardware errors including Single Event Upset (SEU) and latchup. The watchdog utilizes a time layered hierarchy that provides increasing levels of intervention and protection. The 5 layer hierarchy is shown in the figure. Layer 5 reinitializes the processor software code from the point at which the fault occurred. Layer 4 is triggered by the processor bus control ASIC timeout upon processor hang-ups because of SEU or failed processor tasks. Layer 3 is triggered by the external hardware timeout that strobes the processor power when the processor failed to reset the timeout circuit because of latchup, SEU or failed processor tasks. Layer 2 is triggered by the external ground commands to restart the system. Layer 1 is triggered by either the 28-hour Barker watchdog timer or the bypass hardware command which strobe the processor power to reboot the system.
CDH.DESC.9 Deployment Timers
The SCS provides hardware and software timers to initiate events after spacecraft separation.
CDH.DESC.10 Error Detection and Correction (EDAC)
The Bulk Memory and its associated support hardware including the seven check bit data bus on the backplane and an EDAC circuit resided inside the Processor Bus Controller ASIC has the capability of correcting single bit errors and detecting multiple bit errors. The entire bulk memory is scrubbed every TBD minutes by the flight software memory scrubbing task that has the lowest priority.
CDH.DESC.11 WIRE Flight Software
The WIRE flight software runs on the 80386-based processor card in the Spacecraft Computer System. It is responsible for all command and data handling (C&DH) functions as well as the digital attitude control system (ACS) functions. The WIRE flight software is a multi-tasking system, and much of the software is the same as the SAMPEX, SWAS, and TRACE flight software.
Multitasking in the WIRE software is provided by the commercial operating system VRTX (versatile real-time executive) from Microtec Research, Inc. (formerly Ready Systems). The VRTX functions used by the WIRE software are provided by almost any multi-tasking operation system, however. Task creation, startup, priority-based scheduling, and time delay functions are used, as well as message queue creation, posting and pending. The WIRE software bus also uses some of the VRTX memory management functions. All WIRE tasks have a few basic features in common. Each task begins execution at system startup, performs its initialization functions, then pends on its main software bus queue waiting for a message from another task or interrupt service routine (ISR). All tasks maintain a certain amount of housekeeping data that gets included in the telemetry stream from the spacecraft. At a minimum, each task has a ground command count and a command error count in its housekeeping. Each ISR has an "owner" task that is responsible for initializing the routine, enabling the interrupt, and reporting any housekeeping data.
The heart of the software is the scheduler. The scheduler task runs from a 100Hz timer interrupt, and generates commands to the other tasks to schedule all predictable events in the system. All of the scheduling commands, as well as all other software bus messages, are sent in the form of CCSDS packets. The software bus routes all messages to their destination (or destinations) using a routing table. The application ID in the CCSDS packet determines its routing. The command ingest task communicates with the uplink hardware to assemble and validate all ground commands. Valid ground commands are also routed to their destinations using the software bus. The telemetry output task assembles CCSDS transfer frames from the telemetry packets it receives over the software bus. Completed frames are sent to the ground through the downlink hardware. The 1553 bus interface module acts as a bi-directional pipeline between the software bus and the 1553 bus. All of the other flight software functions are handled by additional application tasks, which communicate over the software bus. Sometimes, an application task needs to access a hardware function such as DMA or a timer. If only one task needs to access a particular hardware item, then that task is allowed to communicate with the hardware directly. Otherwise, hardware access is controlled through a common group of library functions. For example, the telemetry output task is given full control of the DMA hardware, but the spacecraft clock hardware can only be accessed through the "get system time" library routine.
The WIRE flight software is organized into six major areas. The attitude control system software (ACS) consists of one or two application tasks plus a math library. The SMEX ACS software has always been developed by a separate group from the C&DH. These two groups must, of course, work closely together. The functions allocated to C&DH are as follows:
System Management (XB, SH, TC, OS, SB): controls the customized backplane and 1553B bus network I/O activity, schedules application tasks, provides spacecraft time keeping services and in-flight adjustment of spacecraft time, provides operating system initialization services, and message routing functions;
-1553B Bus Management (XB) -- provides control over all 1553B bus I/O activities and acts as a bi-directional communications interface between the software bus and the 1553B bus;
-I/O Scheduler (SH) -- provides scheduling of all predictable I/O operations using a cyclic scheduling scheme and synchronizes them to the spacecraft clock (1 Hz pulse);
-Time Code Management (TC) -- provides support for in-flight adjustment of spacecraft time;
-VRTX/OS Initialization (OS) -- provides VRTX operating system initialization services;
-Software Bus (SB) -- provides a collection of service and management functions that control all message routing between tasks and determines the queuing characteristics of data transfers between those tasks;
Command Management (CM): provides the capability for receiving and executing commands from the ground as well as on-board stored commands.
-Command Ingest (CI) -- accepts, validates and distributes real-time commands from the ground, executes stored commands, and supports CCSDS COP-1 protocol;
-Stored Command (SC) -- provides for the autonomous operation of the spacecraft through the processing of on-board stored commands;
Telemetry Management (TM): provides telemetry to the ground, maintains the solid state recorder, and supports the telemetry interface to the launch vehicle;
-Telemetry Output (TO) -- prepares and outputs telemetry to the ground;
-Data Storage and Playback (DS) -- manages the solid state recorder memory;
-Bulk Memory Scrub (MS) - periodically refreshes the solid state recorder memory using the EDAC circuitry
Health and Safety Management (HS): provides bootstrap functions; collects software status, identifies and recovers from upsets and a limited set of spacecraft anomalies and ensures fail-safe operations;
-Housekeeping Data Management (HK) -- provides for the collection and formatting of housekeeping data from the C&DH applications.
-Software Manager (SM) -- provides memory load and dump support and table operations support, provides for periodic monitoring of memory locations within the microprocessor in all modes.
-Telemetry and Statistics Monitor (TS) -- monitors telemetry, applies algorithms to the raw data, performs limit checking, initiates actions on limit failures, and maintains statistical data for each monitor point;
-Self Test (ST) -- performs self-tests of the processor hardware;
-Checksum (CS) -- routinely performs checksumming on static areas of flight memory to detect SEU errors by comparing calculated checksums of these areas against master checksum values.
Payload Management (PM): provides data routing and possibly data compression of science data as well as operation services for the science payload. This may include one or more unique tasks. This is the software area that is created specifically for each individual SMEX mission. All mission unique software requirements are concentrated in these tasks.
CDH.REQ.GEN.0 General C&DH Requirements
The following are general C&DH Requirements
CDH.REQ.GEN.1 Downlink encoding
CDH.REQ.GEN.2 Downlink telemetry rates
CDH.REQ.GEN.3 Uplink decoding
CDH.REQ.GEN.4 Uplink data ambiguity
CDH.REQ.GEN.5 Uplink telemetry rate
CDH.REQ.GEN.6 Telemetry collection
CDH.REQ.GEN.7 Command distribution
CDH.REQ.GEN.8 Pegasus telemetry
CDH.REQ.GEN.9 Hardware decoded reset command
CDH.REQ.GEN.10 Time maintenance
CDH.REQ.GEN.11 Time distribution
CDH.REQ.GEN.12 Telemetry data storage
CDH.REQ.GEN.13 Processor watchdog
CDH.REQ.GEN.14 Spacecraft watchdog
CDH.REQ.GEN.15 Thermistor conditioning
CDH.REQ.GEN.16 Analog telemetry
CDH.REQ.GEN.17 Accomodations for ACS software
CDH.REQ.GEN.18 Transponder control
CDH.REQ.GEN.19 Hardware separation timer
CDH.REQ.GEN.20 Software separation timer
CDH.REQ.GEN.21 ASE discrete commands
CDH.REQ.GEN.22 On-orbit reprogrammability
CDH.REQ.GEN.23 Absolute time sequences
CDH.REQ.GEN.24 Relative time sequences
CDH.REQ.GEN.25 Solar array deployment telemetry
CDH.REQ.GEN.26 No-command timeout
CDH.REQ.INS.0 Instrument Servicing Requirements
The following are instrument servicing requirements:
CDH.REQ.INS.1 Control
CDH.REQ.INS.2 Science data collection
CDH.REQ.INS.3 High speed serial port
CDH.ICD.0 INTERFACES
SCS mechanical
SCS to ACE
Power Distribution
SCS to launch vehicle
SCS to instrument
SCS to transponder
Thermistors
CDH.REL.0 RELATED DOCUMENTS
C&DH Software Requirements Document
CDH.WHO.0 CONTACTS
The C&DH lead is Quang Nguyen.
phone: (301) 286-5951
E-mail: qnam@sunland.gsfc.nasa.gov
The C&DH software lead is Mike Blau.
phone: (301) 286-7880
E-mail: blau@sunland.gsfc.nasa.gov
back to Table of Contents
PWR.DESC.0 DESCRIPTION
The power subsystem is a direct energy transfer (DET), partial array shunt design. The major components of the subsystem are the solar array, battery, and the Spacecraft Power Electronics (SPE). The SPE consists of a control unit and a separate shunt box. The shunt box contains the array shunting transistors.
The power subsystem supplies power to the spacecraft via three buses: the essential bus, the non-essential bus and the pyro bus. The essential bus provides continuous power to essential spacecraft functions. Essential systems include the Spacecraft Computer System, the RF transponder, survival heaters, attitude control system, low-current wax actuators, and the SPE control unit. The non-essential bus provides power to the WIRE instrument, decontamination heaters, operational heaters, and high-current wax actuators. The pyrotechnic bus provides unprotected battery power to fire the pyrotechnic devices. All three buses are routed to the SPE for distribution, switching and fusing (where appropriate). The power subsystem includes an isolation relay to disconnect the non-essential bus in the event that the spacecraft loads are drawing excessive current, the battery is in an undervoltage condition, or when the spacecraft goes into safehold. The essential bus cannot be isolated from the array and battery while the spacecraft is on orbit.
Power generated by the solar panels is supplied directly to the observatory loads through the unregulated buses. Each subsystem provides its own DC-to-DC converter and power conditioning. FET shunt regulators are used to dissipate excess array power, and a Super Nickel-Cadmium (NiCd) battery stack supplies energy when spacecraft power requirements exceed array capability and during eclipse periods. The SPE controls battery charging and dissipation of excess energy through the shunt regulators. All power subsystem electronics are designed in a single string, non-redundant configuration.
The SPE provides primary power distribution and fusing to other spacecraft subsystems, and control and power to the spacecraft's separation and deployment devices. Primary power is distributed over the power buses; essential, non-essential, and pyro, through appropriate relay and fuse circuits. The SPE provides for receipt of power relay commands from the SCS, monitoring of relay status, and collection of internal housekeeping data. The SPE also provides primary current sensing and signal conditioning for the SCS, Attitude Control Electronics (ACE), and transponder. The SPE receives commands and transmits data via the 1553 data bus.
Controlled power distribution via solid-state relays, or direct, non-relayed distribution to the subsystems, is from the essential or non-essential power buses. The SPE also houses the essential and non-essential power return buses. The spacecraft electrical system single point ground is located in the SPE. At this point and no other, the electrical system returns are bused to the spacecraft structure. Solid-state relays are single string. Fusing uses redundant units.
Commands for controlling the power distribution relays are received from the SCS over the 1553 data bus. The SPE electronics decodes the command and provides pulse shaping and current drive to the appropriate relays. A relay state monitor indicates relays status. The SPE transmits relay status data over the 1553 bus when requested.
Commands for controlling the power, solar array, and pyro relays are initiated by the SCS. The SPE command timer also provides a one time power "on" command to the ACE power relays. This function is as back-up to the SCS which provides it under normal conditions.
PWR.REQ.0 REQUIREMENTS
PWR.REQ.GEN.0 General Power System Requirements
The following requirements apply to the entire power system:
PWR.REQ.GEN.1 Bus voltage
PWR.REQ.GEN.2
Bus voltage ripple
PWR.REQ.GEN.3 Bus impedance
PWR.REQ.GEN.4 Bus transients
PWR.REQ.GEN.5 Grounding
PWR.REQ.GEN.6 Pyro Firing
PWR.REQ.SPE.0 SPE Requirements
The following requirements apply to the SPE:
PWR.REQ.SPE.1 Power distribution
PWR.REQ.SPE.2 Battery charge control
PWR.REQ.SPE.3 Amp-hour integrator accuracy
PWR.REQ.SPE.4 Safehold
PWR.REQ.SPE.5 Hardware fault detection
PWR.REQ.SPE.6 Umbilical interface
PWR.REQ.SPE.7 Discrete commands
CDH.REQ.GEN.25 Solar array deployment telemetry
PWR.REQ.SA.0 Solar Array Requirements
The following requirements apply to the solar array:
PWR.REQ.SA.1 End-of-life power
PWR.REQ.BAT.0 Battery Requirements
The following requirements apply to the battery:
PWR.REQ.BAT.1 Capacity
PWR.ICD.0 INTERFACES
SPE mechanical
Power Distribution
Solar array mechanical
SPE to solar arrays
Battery mechanical
SPE to battery
Shunt box mechanical
SPE to shunt box
Heaters
Umbilical
PWR.WHO.0 CONTACTS
The Power system lead is Tom Spitzer.
phone: (301)286-4383
E-mail: Thomas.J.Spitzer.1@gsfc.nasa.gov
The SPE lead is Glen Rakow.
phone: (301)286-5993
E-mail: grakow@sunland.gsfc.nasa.gov
back to Table of Contents
RF.DESC.0 DESCRIPTION
The RF communications subsystem consists of a GSTDN compatible S- band transponder, 3 dB hybrid, 20 dB directional coupler, and two hemispheric omnidirectional antennas. The 3 dB hybrid evenly splits the uplink and downlink RF power between the transponder and the antennas. The directional coupler provides a test port for I&T of the subsystem.
The transponder, manufactured by Loral Conic Terracom, is designed for an uplink carrier frequency of 2039.65 MHz with commands PSK modulated on to a 16 KHz subcarrier. The downlink frequency is 2215.00 MHz and the RF output power is 5 Watts min. Downlink telemetry is phase modulated directly on to the carrier.
The 3 dB hybrid and directional coupler, manufactured by Sage Laboratories, are passive components utilizing stripline designs. Both will be flight qualified units whose housings will be coated with material meeting the program's outgassing requirements. In addition, these units will be designed to meet all GEVS environmental requirements and will undergo thermal shock testing by the manufacturer.
The omni antennas use crossed dipole designs giving excellent gain patterns (up to +4 dB at boresight and -3 dB at 90 degrees off boresight). These antennas have significant heritage, as they are the same designs used by Landsat 4/5, EOS-AM, XTE, and TRMM.
RF.REQ.0 REQUIREMENTS
RF.REQ.1 Uplink frequency
RF.REQ.2 Uplink modulation
RF.REQ.3 Uplink modulation index
RF.REQ.4 Downlink frequency
RF.REQ.5 Downlink modulation
RF.REQ.6 Downlink modulation index
RF.REQ.7 Transmitter power
RF.REQ.8 Antenna coverage
RF.REQ.9 Coherency
CDH.REQ.GEN.5 Uplink data rate
CDH.REQ.GEN.2 Downlink data rates
RF.ICD.0 INTERFACES
Transponder mechanical
Transponder to SCS
Power Distribution
Antenna mechanical
Transponder to antenna
RF system to ground system
Umbilical
RF.WHO.0 CONTACTS
The RF system lead is Mike Powers.
phone: (301) 286-4820
E-mail: michael_powers@ccmail.gsfc.nasa.gov
back to Table of Contents
The WIRE spacecraft uses a passive thermal design, supplemented with heaters. Thermal control will be achieved by material selection, spacecraft configuration, and the use of thermal paints, tapes, and multi-layer insulation blankets. In general, electronics will dissipate their heat directly to their associated equipment panel. The equipment panel will then radiate the heat to space. The rate at which heat is dissipated to and from the equipment panels will be controlled by the use of multi-layer insulation blankets mounted externally to the spacecraft.
THERM.DESC.1 Structure/Radiators
Material selection within the structure of the bus will allow for conductive isolation of each of the equipment panels. This will allow each equipment panel's heat balance to be specifically tailored to the thermal requirements of the component mounted to that panel. Radiative isolation, as needed in the case of the battery, can be achieved for each equipment panel by the use of internal multi-layer insulation. If necessary, heat rejection for the components mounted to the decks or sun-facing equipment panels will be enhanced with strapping, high conductivity materials, and/or enhanced radiation. With the exception of the battery, all internal surfaces of the spacecraft are to be black (anodized or painted) in order to enhance internal radiation. This will allow the access panels to be used as radiator surfaces if additional heat rejection capability is required. High conductivity materials will be used in the equipment panels/radiators.
The deployable solar arrays will be conductively isolated from the spacecraft bus. If needed, low conductivity materials can be used in the solar array mounting mechanisms. The solar array temperature testing requirements will be determined by analysis.
The battery will be thermally isolated from the rest of the spacecraft.
The star tracker is located on anti-sun side of the bus/instrument interface and is thermally isolated from the rest of the spacecraft. Coatings, blanketing, and heaters will be used to meet the star tracker's thermal requirements. The external portion of the star tracker shade will be blanketed.
To minimize parasitic heat loading from the bus to the instrument cryostat, the instrument support struts will be designed to minimized thermal conduction. The struts may either be painted or blanketed. Struts with a high emittance coating may be used to intercept and reject parasitic heat loads from the spacecraft bus.
The top of the spacecraft bus will be insulated with multi-layer blanketing in order to minimize radiation to the cryostat exterior.
Harnessing from the cold instrument optics to the electronics mounted within the bus will be with low conductivity materials and a specified harness length to minimize heat leaks to the cryostat.
The WIRE thermal control system (TCS) will utilize two heater circuits. An operational circuit will supplement the passive control during cold operational periods. A survival circuit will provide needed heat to the spacecraft during launch, safehold, and contingency situations to keep components above their survival/turn on operational limits. Heaters will be selected and sized based on location and bus voltage requirements. Redundant thermostats will control each heater.
THERM.DESC.7 Temperature Monitoring
The spacecraft computer will control a set of thermistors to monitor spacecraft temperatures. Each subsystem component will have internal thermistors mounted in key locations. The wiring for these thermistors will be included in the component's connectors and harnessing. Other thermistors will be located throughout the spacecraft to monitor key structural and interface locations. These thermistors will be individually wired back to the computer since they lie external to any specific component. It is expected that the spacecraft computer will monitor key instrument locations by the use of thermistors and/or platinum and germanium thermometers.
THERM.REQ.1 Pre-launch temperature range
THERM.REQ.2 Instrument heat load
THERM.REQ.3 Orbit temperature stability
THERM.REQ.4 Mission temperature stability
THERM.REQ.5 Heater bus voltage range
THERM.ICD.0 INTERFACES
Power Distribution
Thermistor and heater mounting
Thermistors
Heaters
THERM.WHO.0 CONTACTS
The thermal system lead is Kim Brown.
phone: (301) 286-2627
E-mail: Kimberly.D.Brown.1@gsfc.nasa.gov
back to Table of Contents
HAR.DESC.0 DESCRIPTION
The harness is the electrical wiring throughout the spacecraft.
HAR.REQ.0 REQUIREMENTS
HAR.REQ.1 Instrument to WIE box
HAR.REQ.2Redundant power lines
HAR.REQ.3
HAR.ICD.0 INTERFACES
HAR.WHO.0 CONTACTS
The harness lead is Bahe Rock.
phone: (301) 286-6561
E-mail: Bahe.Rock@gsfc.nasa.gov
back to Table of Contents
GSE.DESC.0 DESCRIPTION
GSE.DESC.1 ASE
The Airborne Support Equipment interfaces directly to the umbilical of the spacecraft. It provides power and critical telemetry monitoring during ground testing and captive carry (see launch system). It interfaces to the I&T GSE for spacecraft hardline telemetry and commands.
GSE.DESC.2 I&T GSE
I&T GSE will handle real-time spacecraft communications, and provide test control and test monitoring capabilities to validate the spacecraft performance and readiness for flight during various phases of spacecraft testing including subsystem, ETU, flight, and pre-launch. Telemetry processing capability will be required for monitoring spacecraft status, health and safety information, and for distributing telemetry data to subsystem GSE's such as the C&DH, ACS, Power, and Instrument subsystems. For telecommmand processing, I&T GSE will be capable of validating and formatting commands issued by the Test Conductor in mnemonic format and transmitting the commands to the spacecraft. The raw telemetry stream shall be archived on digital tape. Formatted telemetry data shall be archived on hard disk drive for playback purposes. I&T GSE will also receive command blocks from the POCC to be forward to the Spacecraft to verify that the POCC can command the spacecraft and send telemetry blocks from the Spacecraft to POCC to verify that the POCC can process spacecraft telemetry. The command and telemetry blocks will be sented over the NASA communication network to the I&T GSE during Spacecraft to POCC compatibility test.
The I&T GSE operational configuration consist of 3 mojor elements: the Front-End Communications System (FCS), the Front-End Telemetry and Command Processor (FTCP), the Test Conductor Workstation (TCW), the Local Area Network (LAN), and the subsystem GSEs. They functionally provide the end-to-end data handling between the onboard subsystems and their subsystem GSEs.
During the spacecraft integration and test, the telemetry data flows from the spacecraft through the FCS, FTCP, and LAN to the TCW and the subsystem GSEs. The FCS accepts the modulated telemetry from the spacecraft, and then performs demodulation, convolutional decoding, and bit synchronization. In addition, the FCS records all telemetry to the high speed digital recorder for later use. The outputs from the FCS are a serial digital bitstream and synchronization clock.
The FTCP synchronizes the incoming bitstream and clock output from FCS, reassembles the source packets from the CCSDS transfer frames and virtual channels, arranges them into a standard format, and forwards them over the LAN to the TCW . The TCW accepts the reassembled telemetry packets, extracts the spacecraft housekeeping data and processes them in real time. In addition, the TCW distributes the telemetry packets to the other Subsystem GSE and Instrument GSE as requested.
In the opposite direction, the telecommand flows from the TCW through the LAN, FTCP, and FCS to the spacecraft. The FTCP accepts the telecommand transfer frame from the LAN, performs the Code Block Encoding on the telecommand transfer frame, and formats it into a Command Link Transmission Unit (CLTU). The FTCP then sends the CLTU to the spacecraft through the FCS.
GSE.REQ.0 REQUIREMENTS
GSE.REQ.GEN.0 General Requirements
The following apply generally to the GSE:
GSE.REQ.GEN.1 Downlink decoding
GSE.REQ.GEN.2 Uplink encoding
GSE.REQ.GEN.3 Pegasus telemetry decommutation
GSE.REQ.GEN.4 Pegasus simulator
GSE.REQ.GEN.5 Maximum housekeeping rate
GSE.REQ.GEN.6 Subsystem workstations
GSE.REQ.GEN.7 Science telemetry distribution
GSE.REQ.GEN.8 Instrument command loads
GSE.REQ.GEN.9 Data distribution to ground system
GSE.REQ.GEN.10 Command reception from ground system
GSE.REQ.GEN.11 Data archival
GSE.REQ.GEN.12 Telemetry playback
GSE.REQ.GEN.13 Database maintenance
GSE.REQ.GEN.14 Event logging
GSE.REQ.GEN.15 Spacecraft test and operations language
GSE.REQ.GEN.16 Subsystem GSE support
GSE.REQ.GEN.17 Real-time plotting
GSE.REQ.GEN.18 Plotting of stored trending data
GSE.REQ.GEN.19 Limit checking
SAF.REQ.2 Critical commands
GND.REQ.GEN.5 Bit Synchronizer Capabilities
CDH.REQ.GEN.5 Uplink data rate
CDH.REQ.GEN.2 Downlink data rates
GSE.ICD.0 INTERFACES
Spacecraft Launch vehicle
GSE.WHO.0 CONTACTS
The spacecraft I&T GSE lead is Tawanda Jacobs
phone:(301) 286-9103
E-mail: Tawanda.Jacobs@gsfc.nasa.gov
back to Table of Contents
VEH.DESC.0 DESCRIPTION
The baseline launch vehicle for WIRE is the Pegasus XL. The Pegasus is launched from an L-1011 off the coast of California after a one hour captive carry. L-1011 takeoff is from Vandenberg Air Force Base in California.
Spacecraft activities at Vandenberg will include final spacecraft inspection, mate to launch vehicle, hydrogen loading, final arming and fairing closeout, final powerup, and takeoff.
Upon arrival at Vandenberg and before the hydrogen loading, the spacecraft functional (VER.REQ.2) and an ACS sensor aliveness test will be run and the solar array will be inspected.
Mate to the Pegasus will occur in building 1555. The launch-day power-up procedure will be run prior to flight simulations #3 and #4.
The cryostat will be filled with hydrogen at the Astrotech (TBD) facility at Vandenberg.
Because the launch vehicle is carried by a manned aircraft and the interior of the Pegasus fairing contains powered equipment which is not explosion proof, the spacecraft design must preclude venting of hydrogen into the fairing.
VEH.REQ.0 REQUIREMENTS
VEH.REQ.GEN.0 General Launch System Requirements
VEH.REQ.GEN.1 Orbit
VEH.REQ.GEN.2 Tip-off
VEH.REQ.GEN.3 Mass to orbit
VEH.REQ.GEN.4 Emergency vent back pressure
VEH.REQ.GEN.5 fairing cleanliness
VEH.REQ.GEN.6 fairing air conditioning
VEH.REQ.GEN.7 attach-ring cleanliness
VEH.REQ.GEN.8 clean-room cleanliness
VEH.REQ.GEN.9 clean-room air conditioning
VEH.REQ.FILL.0 Hydrogen Fill Requirements
The following requirements apply to the hydrogen fill:
VEH.REQ.FILL.1 hydrogen handling
VEH.REQ.FILL.2 provisions for GSE
VEH.REQ.MATE.0 Vehicle Mate Requirements
The following requirements apply to vehicle mate:
VEH.REQ.MATE.1 hydrogen handling
VEH.REQ.MATE.2 provisions for GSE
VEH.REQ.MATE.3 provisions for spacecraft tests
VEH.REQ.HP.0 Hot Pad Testing Requirements
The following requirements apply to hot pad testing:
VEH.REQ.HP.1 hydrogen handling
VEH.REQ.HP.2 provisions for GSE
VEH.REQ.HP.3 provisions for spacecraft tests
VEH.REQ.HP.4 fairing access
VEH.REQ.CAR.0 Captive Carry Requirements
The following requirements apply to captive carry testing:
VEH.REQ.CAR.1 provisions for GSE
VEH.REQ.CAR.2 communications links
VEH.REQ.CAR.3 launch panel operator
VEH.ICD.0 INTERFACES
Spacecraft structure
Umbilical
Instrument
VEH.WHO.0 CONTACTS
The OLS WIRE system manager is Bob Vernier
phone: (301) 344-4969
E-mail: Bob.Vernier@ccmail.gsfc.nasa.gov
The OSC WIRE vehicle manager is Dave Spiegelthal
phone: (703) 406-5088
E-mail:spiegelthal.dave@orbital.com
back to Table of Contents
GND.DESC.0 DESCRIPTION
The SMEX ground system consists of the Mission Operations Center (MOC), ground stations, Flight Dynamics Division (FDD), and the launch site. This architecture was developed for TRACE and is currently planned for reuse on the WIRE mission. All elements are connected by the MO&DSD Operations Development Network (MODNet).
Mission Operations Center (MOC)
The MOC is physically divided into the Mission Operations Room (MOR) and the Mission Analysis Room (MAR). Functionally, the MOC is composed of the Real-Time System and the Off-Line System. In general, the Real-Time System operates in the MOR and the Off-Line System operates in the MAR, although there is no physical reason preventing any function from being performed in any location.
Real-Time System
The real-time system is the primary FOT interface for command and control, and spacecraft health and safety monitoring. It generates commands, initiated by FOT or CMS input, and forwards them to the ground stations via Nascom, for uplink. The real-time system receives the composite telemetry stream or stripped Virtual Channels (VC) from the ground stations through Nascom. Decommutation, calibration, and limit checks are performed on the engineering telemetry stream. Engineering data storage for up to 30 days, real-time system hardware and software, and history recording capabilities are provided together with scheduling interfaces to the lead scheduler element.
Off-Line System
The off-line system consists of the Command Management System (CMS), Data Processing System (DPS), and the Attitude Determination System (ADS).
Command Management System (CMS)
The CMS function consists of an MAR-based workstation which will provide command planning and management services. This unit, utilizing FDD, FOT, PI, flight software maintenance, and Project inputs, generates pass plans and loads needed to perform spacecraft operations.
Data Processing System (DPS)
The DPS receives the composite telemetry stream from the ground stations in real time (or shortly after LOS). It is a workstation based system which can reside either in the MOC or in the PI's Science Operations Center. It performs data quality checking, removing communications artifacts and redundant data, sorting, time ordering, assembly of the data into packets, and science data storage.
Attitude Determination System (ADS)
The ADS is located in the MAR. It is the primary system for the analysis of Attitude Control Subsystem (ACS) data and is used by FDF to verify ACS performance and attitude solutions. The ADS also generates attitude products for the project and science team.
Ground Stations
Communications between the spacecraft and the ground facilities are provided through the Wallops Island Orbital Tracking Station (WPS) at WFF; a Wallops provided Transportable Orbital Tracking Station (TOTS) stationed at Poker Flat, Alaska; and the DSN ground stations at Goldstone (DSS-16/DSS-17), Canberra (DSS-46), and Madrid (DSS-66). DSN stations are currently used only for Launch and Early Orbit (L&EO) activities and for contingency backup support.
Flight Dynamics Division
The FDD provides orbit, attitude, mission analysis support acquisition, and scheduling data for the mission. The FDD receives tracking data from ground stations and has access to the ADS in the MAR. Although the FDD is continuously available for data receipt, FDD analysts will not support on a 24-hour-a-day, 7-day-a-week basis. The majority of FDD support is provided on weekdays during the prime shift.
Launch Site
Mission operations activities at the launch site require communications to support integration and End-to-end (ETE) testing, operations simulations, and launch. Voice and data communications are required between the launch site and GSFC. Nascom provides data switching and monitoring capabilities.
Nascom
Nascom provides the voice and data communications circuits among all the supporting elements of SMEX missions from Integration and Test (I&T) through the launch and operations phases. Data communications utilize the MODNet, which is a Nascom supported network based on the commercial Internet Protocol (IP). The MOC and FDD are typically within the secure perimeter of the closed MODNet. Security gateways and firewalls provide access from the closed MODNet to the "open" (unsecured) MODNet and the Internet. The unsecure networks allow connectivity to the Science Operations Center and other remote facilities (if necessary).
GND.REQ.0 REQUIREMENTS
GND.REQ.1 Ground station G/T
GND.REQ.2 Orbit Determination
GND.REQ.3 Ephemeris Accuracy
GND.REQ.4 Attitude Determination
GND.REQ.5 Bit Synchronizer Capabilities
GND.REQ.6 Daily downlink volume
GND.REQ.7 Spacecraft Clock Maintenance
GND.REQ.8 Spacecraft Bulk Memory Management
GND.REQ.9 Health and Safety Monitoring
GND.REQ.10 Data Storage/Archiving
GND.REQ.11 Science Data Processing
GND.REQ.12 CCSDS Implementation
GND.REQ.13 Command Management
GND.REQ.14 Network Scheduling
GND.REQ.15 Daily uplink volume
CDH.REQ.GEN.5 Uplink data rate
CDH.REQ.GEN.2 Downlink data rates
RF.REQ.1 Uplink frequency
RF.REQ.2 Uplink modulation
RF.REQ.3 Uplink modulation index
RF.REQ.4 Downlink frequency
RF.REQ.5 Downlink modulation
RF.REQ.6 Downlink modulation index
GSE.REQ.GEN.1 Downlink decoding
GSE.REQ.GEN.2 Uplink encoding
GND.ICD.0 INTERFACES
GND.WHO.0 CONTACTS
The Mission Operations Manager is John Catena.
phone: (301) 286-9572
E-mail: John.Catena@ccmail.gsfc.nasa.gov
back to Table of Contents
Date: October 20, 1997
