SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
A computer program has been developed to provide a common interface for all space mission data, and allows different types of data to be displayed in the same context. This software provides an infrastructure for representing any type of mission data.
A real time dynamic simulator for LANDSAT D was developed and has played an integral role in the development and validation of both the ground control system and of the on-board flight software. The simulator utilized an electronic replica of the spacecraft on-board computer and data handling hardware interfaced to a VAX 11/780 computer and simulation software. Key features of the simulator design are a modular software architecture tailored to the VAX/VMS real time capabilities, a microprocessor controlled interface between the VAX and the flight hardware replica, complete simulation of the spacecraft and NASA network communication links, and a flexible and powerful scenario structuring and operator control capability. The design goals and trade-offs, software, and hardware design are summarized. The application of the simulator to the validation of both the ground systems and on-board software is reviewed in detail.
Spacecraft applications that interact with on-board sensors, effectors, and major components have traditionally used private interfaces which are tightly bound to the interface details of the data links connecting these sub-systems. The latest spacecraft, which often include several powerful processors running real time operating systems, high-speed on-board networks, and intelligent peripherals, can support a more layered networked environment. Use of standard interfaces and networked elements is expected to yield reusable software and hardware components. Within CCSDS Panel 1K we have been developing such on-board interface standards. This paper will present a Message Transfer Service that defines a common API for use within a single spacecraft or among spacecraft flying in a constellation.
The Utah State University space system design project for 1989 to 1990 focuses on the design of a global electrical field sensing system to be deployed in a constellation of microspacecraft. The design includes the selection of the sensor and the design of the spacecraft, the sensor support subsystems, the launch vehicle interface structure, on board data storage and communications subsystems, and associated ground receiving stations. Optimization of satellite orbits and spacecraft attitude are critical to the overall mapping of the electrical field and, thus, are also included in the project. The spacecraft design incorporates a deployable sensor array (5 m booms) into a spinning oblate platform. Data is taken every 0.1 seconds by the electrical field sensors and stored on-board. An omni-directional antenna communicates with a ground station twice per day to down link the stored data. Wrap-around solar cells cover the exterior of the spacecraft to generate power. Nine Pegasus launches may be used to deploy fifty such satellites to orbits with inclinations greater than 45 deg. Piggyback deployment from other launch vehicles such as the DELTA 2 is also examined.
The design is reported of a dual mode multispectral scanner, capable of satisfying both overland and oceanographic requirements. A complete system description and performance summary of the scanner are given. In addition, subsystem and component descriptions and performance analyses are treated in individual sections. The design of the scanner, with minimum modifications, interfaces to the ERTS spacecraft and the ground data handling system.
The objectives of magnetic field investigations on missions to the outer planets were defined as well as an instrumentation system, a program of studies and instrument development tasks was proposed for the mission definition phase of the Outer Planets Grand Tour project. A report on the status of this program is given. Requirements were also established for the spacecraft and the mission which would insure their compatibility with the magnetic field investigation proposed for the outer planets missions and developed figures of merit for encounter trajectories. The spacecraft-instrumentation interface and the on-board data handling system were defined in various reports by the Project Team and in the reports by the Science Steering Group. The defining program for exploring the outer planets within the more restrictive constraints of the Mariner Jupiter-Saturn project included defining a limited magnetic field investigation.
Five accelerometers mounted near the adapter base of the Titan 3-C launch vehicle and three on the hub of the ATS-F spacecraft provided (1) data for verifying basic spacecraft mode shapes and frequencies during powered flight while attached to the launch vehicle; (2) failure mode detection and diagnostic information on in-flight anomalies; and (3) data to be used in the design of future spacecraft to be flown on the Titan 3-C. Because data from the instruments mounted on the spacecraft hub passed through an in-flight disconnect at the separation plane between the transtage and ATS-F, the moment this connector was broken, the signal to the telemetry system showed a step function change. By monitoring these telemetry traces on the ground at appropriate times during flight sequences, a positive indication of spacecraft separation was obtained. Flight data showing dynamic response at spacecraft launch vehicle interface and at the top of ATS spacecraft during significant launch events are presented in tables.
The scientific experiments package to be carried by the Proteus system takes the form of an Instrument Load carried into orbit by a Space Shuttle, and there mated to a Proteus spacecraft with the Shuttle's Remote Manipulator System. The Proteus system extends to ground support equipment, development tools, and communications, as well as the orbiting satellites. It is expected that Proteus will be able to triple the number of Explorer missions while staying within the current budgetary allocation for such missions. The Proteus spacecraft encompasses a system interface assembly plug, a data handling module, remote interface units, and a power distribution module.
This paper discusses the formulation and execution of a laboratory test of the electrical interfaces between multiple atmospheric science instruments and the spacecraft bus that carries them. The testing, performed in 2002, used engineering models of the instruments that will be flown on the Aura s p a c m and of the Aura spacecraft bus electronics. Aura is one of NASA's Earth Observing System @OS) Program missions managed by the Goddard Space Flight Center. The test was designed to evaluate the complex interfaces in the spacecraft and instrument command and data handling (C&DH) subsystems prior to integration of the complete flight instruments on the spacecraft. A problem discovered during (and not before) the flight hardware integration phase can cause significant cost and schedule impacts. The testing successfully surfaced problems and led to their resolution before the full-up integration phase, saving significant cost and schedule time. This approach could be used on future environmental satellite programs involving multiple, complex scientific instruments being integrated onto a bus.
An outstanding problem in spaceflight is the lack of adequate sensors for monitoring the space environment and its effects on engineering systems. By adequate, we mean low cost in terms of mission impact (e.g., low price, low mass/size, low power, low data rate, and low design impact). The New Millennium Program (NMP) is investigating the development of such a low-cost Space Environmental Monitor (SEM) package for inclusion on its technology validation flights. This effort follows from the need by NMP to characterize the space environment during testing so that potential users can extrapolate the test results to end-use conditions. The immediate objective of this effort is to develop a small diagnostic sensor package that could be obtained from commercial sources. Environments being considered are: contamination, atomic oxygen, ionizing radiation, cosmic radiation, EMI, and temperature. This talk describes the requirements and rational for selecting these environments and reviews a preliminary design that includes a micro-controller data logger with data storage and interfaces to the sensors and spacecraft. If successful, such a sensor package could be the basis of a unique, long term program for monitoring the effects of the space environment on spacecraft systems.
An outstanding problem in spaceflight is the lack of adequate sensors for monitoring the space environment and its effects on engineering systems. By adequate, we mean low cost in terms of mission impact (e.g., low price, low mass/size, low power, low data rate, and low design impact). The New Millennium Program (NMP) is investigating the development of such a low-cost Space Environmental Monitor (SEM) package for inclusion on its technology validation flights. This effort follows from the need by NMP to characterize the space environment during testing so that potential users can extrapolate the test results to end-use conditions. The immediate objective of this effort is to develop a small diagnostic sensor package that could be obtained from commercial sources. Environments being considered are: contamination, atomic oxygen, ionizing radiation, cosmic radiation, EMI, and temperature. This talk describes the requirements and rational for selecting these environments and reviews a preliminary design that includes a micro-controller data logger with data storage and interfaces to the sensors and spacecraft. If successful, such a sensor package could be the basis of a unique, long term program for monitoring the effects of the space environment on spacecraft systems.
This paper discusses the basis for the Model Payload and how it was used to develop the mission design, observation and data acquisition strategy, needed spacecraft capabilities, spacecraft-payload interface needs, mission system requirements and operational scenarios.
The Radio Frequency Health Node (RFHN) wireless sensor system differs from other wireless sensor systems in ways originally intended to enhance utility as an instrumentation system for a spacecraft. The RFHN can also be adapted to use in terrestrial applications in which there are requirements for operational flexibility and integrability into higher-level instrumentation and data acquisition systems. As shown in the figure, the heart of the system is the RFHN, which is a unit that passes commands and data between (1) one or more commercially available wireless sensor units (optionally, also including wired sensor units) and (2) command and data interfaces with a local control computer that may be part of the spacecraft or other engineering system in which the wireless sensor system is installed. In turn, the local control computer can be in radio or wire communication with a remote control computer that may be part of a higher-level system. The remote control computer, acting via the local control computer and the RFHN, cannot only monitor readout data from the sensor units but can also remotely configure (program or reprogram) the RFHN and the sensor units during operation. In a spacecraft application, the RFHN and the sensor units can also be configured more nearly directly, prior to launch, via a serial interface that includes an umbilical cable between the spacecraft and ground support equipment. In either case, the RFHN wireless sensor system has the flexibility to be configured, as required, with different numbers and types of sensors for different applications. The RFHN can be used to effect realtime transfer of data from, and commands to, the wireless sensor units. It can also store data for later retrieval by an external computer. The RFHN communicates with the wireless sensor units via a radio transceiver module. The modular design of the RFHN makes it possible to add radio transceiver modules as needed to accommodate additional sets of wireless sensor units. The RFHN includes a core module that performs generic computer functions, including management of power and input, output, processing, and storage of data. In a typical application, the processing capabilities in the RFHN are utilized to perform preprocessing, trending, and fusion of sensor data. The core module also serves as the unit through which the remote control computer configures the sensor units and the rest of the RFHN.
The Power and Attitude Control Expert System (PACES) is an object oriented and rule based expert system which provides spacecraft engineers with assistance in isolating and correcting problems within the Power and Attitude Control Subsystems of the Tracking and Data Relay Satellites (TDRS). PACES is designed to act in a consultant role. It will not interface to telemetry data, thus preserving full operator control over spacecraft operations. The spacecraft engineer will input requested information. This information will include telemetry data, action being performed, problem characteristics, spectral characteristics, and judgments of spacecraft functioning. Questions are answered either by clicking on appropriate responses (for text), or entering numeric values. A context sensitive help facility allows access to additional information when the user has difficulty understanding a question or deciding on an answer. The major functionality of PACES is to act as a knowledge rich system which includes block diagrams, text, and graphics, linked using hypermedia techniques. This allows easy movement among pieces of the knowledge. Considerable documentation of the spacecraft Power and Attitude Control Subsystems is embedded within PACES. The development phase of TDRSS expert system technology is intended to provide NASA with the necessary expertise and capability to define requirements, evaluate proposals, and monitor the development progress of a highly competent expert system for NASA's Tracking and Data Relay Satellite Program.
The Euclid mission objective is to understand why the expansion of the Universe is accelerating through by mapping the geometry of the dark Universe by investigating the distance-redshift relationship and tracing the evolution of cosmic structures. The Euclid project is part of ESA's Cosmic Vision program with its launch planned for 2020 (ref [1]). The NISP (Near Infrared Spectrometer and Photometer) is one of the two Euclid instruments and is operating in the near-IR spectral region (900- 2000nm) as a photometer and spectrometer. The instrument is composed of: - a cold (135K) optomechanical subsystem consisting of a Silicon carbide structure, an optical assembly (corrector and camera lens), a filter wheel mechanism, a grism wheel mechanism, a calibration unit and a thermal control system - a detection subsystem based on a mosaic of 16 HAWAII2RG cooled to 95K with their front-end readout electronic cooled to 140K, integrated on a mechanical focal plane structure made with molybdenum and aluminum. The detection subsystem is mounted on the optomechanical subsystem structure - a warm electronic subsystem (280K) composed of a data processing / detector control unit and of an instrument control unit that interfaces with the spacecraft via a 1553 bus for command and control and via Spacewire links for science data This presentation describes the architecture of the instrument at the end of the phase C (Detailed Design Review), the expected performance, the technological key challenges and preliminary test results obtained for different NISP subsystem breadboards and for the NISP Structural and Thermal model (STM).
Three documents provide information on a digital processing unit (DPU) for the planned Aquarius mission, in which a radiometer aboard a spacecraft orbiting Earth is to measure radiometric temperatures from which data on sea-surface salinity are to be deduced. The DPU is the interface between the radiometer and an instrument-command-and-data system aboard the spacecraft. The DPU cycles the radiometer through a programmable sequence of states, collects and processes all radiometric data, and collects all housekeeping data pertaining to operation of the radiometer. The documents summarize the DPU design, with emphasis on innovative aspects that include mainly the following: a) In the radiometer and the DPU, conversion from analog voltages to digital data is effected by means of asynchronous voltage-to-frequency converters in combination with a frequency-measurement scheme implemented in field-programmable gate arrays (FPGAs). b) A scheme to compensate for aging and changes in the temperature of the DPU in order to provide an overall temperature-measurement accuracy within 0.01 K includes a high-precision, inexpensive DC temperature measurement scheme and a drift-compensation scheme that was used on the Cassini radar system. c) An interface among multiple FPGAs in the DPU guarantees setup and hold times.
The document is a reference document in the Instrument Interface Description for NOAA-2000 Instruments (GSFC-S-480-53). The requirements reflect the fact that these instruments must be compatible with a number of different polar orbiting satellite vehicles including the NOAA-OPQ satellites and the EUMETSAT METOP satellites. The instrument payload will interface to the spacecraft via several standardized communication busses. The document defines a uni-directional point-to-point single-user interface for transfer of high rate data (greater than 100 kbs) between instruments and a spacecraft system.
NASA's James Webb Space Telescope (JWST) faces difficult technical and budgetary challenges to overcome before it is scheduled launch in 2010. The Integrated Science Instrument Module (ISIM), shares these challenges. The major challenge addressed in this paper is the data network used to collect, process, compresses and store Infrared data. A total of 114 Mbps of raw information must be collected from 19 sources and delivered to the two redundant data processing units across a twenty meter deployed thermally restricted interface. Further data must be transferred to the solid-state recorder and the spacecraft. The JWST detectors are kept at cryogenic temperatures to obtain the sensitivity necessary to measure faint energy sources. The Focal Plane Electronics (FPE) that sample the detector, generate packets from the samples, and transmit these packets to the processing electronics must dissipate little power in order to help keep the detectors at these cold temperatures. Separating the low powered front-end electronics from the higher-powered processing electronics, and using a simple high-speed protocol to transmit the detector data minimize the power dissipation near the detectors. Low Voltage Differential Signaling (LVDS) drivers were considered an obvious choice for physical layer because of their high speed and low power. The mechanical restriction on the number cables across the thermal interface force the Image packets to be concentrated upon two high-speed links. These links connect the many image packet sources, Focal Plane Electronics (FPE), located near the cryogenic detectors to the processing electronics on the spacecraft structure. From 12 to 10,000 seconds of raw data are processed to make up an image, various algorithms integrate the pixel data Loss of commands to configure the detectors as well as the loss of science data itself may cause inefficiency in the use of the telescope that are unacceptable given the high cost of the observatory. This combination of requirements necessitates a redundant, fault tolerant, high- speed, low mass, low power network with a low Bit error Rate(1E-9- 1E-12). The ISIM systems team performed many studies of the various network architectures that meeting these requirements. The architecture selected uses the Spacewire protocol, with the addition of a new transport and network layer added to implement end-to-end reliable transport. The network and reliable transport mechanism must be implemented in hardware because of the high average information rate and the restriction on the ability of the detectors to buffer data due to power and size restrictions. This network and transport mechanism was designed to be compatible with existing Spacewire links and routers so that existing equipment and designs may be leveraged upon. The transport layer specification is being coordinated with European Space Agency (ESA), Spacewire Working Group and the Consultative Committee for Space Data System (CCSDS) PlK Standard Onboard Interface (SOIF) panel, with the intent of developing a standard for reliable transport for Spacewire. Changes to the protocol presented are likely since negotiations are ongoing with these groups. A block of RTL VHDL that implements a multi-port Spacewire router with an external user interface will be developed and integrated with an existing Spacewire Link design. The external user interface will be the local interface that sources and sinks packets onto and off of the network (Figure 3). The external user interface implements the network and transport layer and handles acknowledgements and re-tries of packets for reliable transport over the network. Because the design is written in RTL, it may be ported to any technology but will initially be targeted to the new Actel Accelerator series (AX) part. Each link will run at 160 Mbps and the power will be about 0.165 Watt per link worst case in the Actel AX.