Search NASA⌕ Search

SEARCH · Search NASA

Results for “Computer Operations and Hardware”

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.

At least 109 records · Page 6

Design and implementation of a Windows NT network to support CNC activities

The Manufacturing, Materials, & Processes Technology Division is undergoing dramatic changes to bring it's manufacturing practices current with today's technological revolution. The Division is developing Computer Automated Design and Computer Automated Manufacturing (CAD/CAM) abilities. The development of resource tracking is underway in the form of an accounting software package called Infisy. These two efforts will bring the division into the 1980's in relationship to manufacturing processes. Computer Integrated Manufacturing (CIM) is the final phase of change to be implemented. This document is a qualitative study and application of a CIM application capable of finishing the changes necessary to bring the manufacturing practices into the 1990's. The documentation provided in this qualitative research effort includes discovery of the current status of manufacturing in the Manufacturing, Materials, & Processes Technology Division including the software, hardware, network and mode of operation. The proposed direction of research included a network design, computers to be used, software to be used, machine to computer connections, estimate a timeline for implementation, and a cost estimate. Recommendation for the division's improvement include action to be taken, software to utilize, and computer configurations.

Shearrow, C. A.↗

Testing for the J-2X Upper Stage Engine

NASA selected the J-2X Upper Stage Engine in 2006 to power the upper stages of the Ares I crew launch vehicle and the Ares V cargo launch vehicle. Based on the proven Saturn J-2 engine, this new engine will provide 294,000 pounds of thrust and a specific impulse of 448 seconds, making it the most efficient gas generator cycle engine in history. The engine's guiding philosophy emerged from the Exploration Systems Architecture Study (ESAS) in 2005. Goals established then called for vehicles and components based, where feasible, on proven hardware from the Space Shuttle, commercial, and other programs, to perform the mission and provide an order of magnitude greater safety. Since that time, the team has made unprecedented progress. Ahead of the other elements of the Constellation Program architecture, the team has progressed through System Requirements Review (SRR), System Design Review (SDR), Preliminary Design Review (PDR), and Critical Design Review (CDR). As of February 2010, more than 100,000 development engine parts have been ordered and more than 18,000 delivered. Approximately 1,300 of more than 1,600 engine drawings were released for manufacturing. A major factor in the J-2X development approach to this point is testing operations of heritage J-2 engine hardware and new J-2X components to understand heritage performance, validate computer modeling of development components, mitigate risk early in development, and inform design trades. This testing has been performed both by NASA and its J-2X prime contractor, Pratt & Whitney Rocketdyne (PWR). This body of work increases the likelihood of success as the team prepares for testing the J-2X powerpack and first development engine in calendar 2011. This paper will provide highlights of J-2X testing operations, engine test facilities, development hardware, and plans.

Buzzell, James C.↗

Earth Observatory Satellite system definition study. Report no. 3: Design/cost tradeoff studies. Appendix A: EOS program WBS dictionary. Appendix B: EOS mission functional analysis

The work breakdown structure (WBS) dictionary for the Earth Observatory Satellite (EOS) is defined. The various elements of the EOS program are examined to include the aggregate of hardware, computer software, services, and data required to develop, produce, test, support, and operate the space vehicle and the companion ground data management system. A functional analysis of the EOS mission is developed. The operations for three typical EOS missions, Delta, Titan, and Shuttle launched are considered. The functions were determined for the top program elements, and the mission operations, function 2.0, was expanded to level one functions. Selection of ten level one functions for further analysis to level two and three functions were based on concern for the EOS operations and associated interfaces.

Source record↗

Processing laser velocimeter high-speed burst counter data

The statistical calculations of the mean and potential bias errors are considered with respect to their applicability to the randomly sampled velocity data obtained from a laser velocimeter. Techniques for displaying the resulting data in the form of arrow plots, flow streamline plots, and contour maps are also discussed. A description is presented of the operation of a new hardware interface between the signal processing electronics and the computer. The interface has been constructed to make it possible to use recently developed data processing techniques for obtaining turbulent power spectra from laser velocimeter data. Additional capabilities which were built into the interface allow the measurement of the velocity vector for each particle passing through the laser velocimeter sample window. By processing the data with extended versions of the turbulent power spectra techniques, cross spectra, interactions between velocity magnitude fluctuations, and flow angle fluctuations may be investigated.

Meyers, J. F.↗

Operational procedures for ground station operation: ATS-3 Hawaii-Ames satellite link experiment

Hardware description and operational procedures for the ATS-3 Hawaii-Ames satellite computer link are presented in basic step-by-step instructions. Transmit and receive channels and frequencies are given. Details such as switch settings for activating the station to the sequence of turning switches on are provided. Methods and procedures for troubleshooting common problems encountered with communication stations are also provided.

Nishioka, K.↗

Mathematical models for space shuttle ground systems

Math models are a series of algorithms, comprised of algebraic equations and Boolean Logic. At Kennedy Space Center, math models for the Space Shuttle Systems are performed utilizing the Honeywell 66/80 digital computers, Modcomp II/45 Minicomputers and special purpose hardware simulators (MicroComputers). The Shuttle Ground Operations Simulator operating system provides the language formats, subroutines, queueing schemes, execution modes and support software to write, maintain and execute the models. The ground systems presented consist primarily of the Liquid Oxygen and Liquid Hydrogen Cryogenic Propellant Systems, as well as liquid oxygen External Tank Gaseous Oxygen Vent Hood/Arm and the Vehicle Assembly Building (VAB) High Bay Cells. The purpose of math modeling is to simulate the ground hardware systems and to provide an environment for testing in a benign mode. This capability allows the engineers to check out application software for loading and launching the vehicle, and to verify the Checkout, Control, & Monitor Subsystem within the Launch Processing System. It is also used to train operators and to predict system response and status in various configurations (normal operations, emergency and contingent operations), including untried configurations or those too dangerous to try under real conditions, i.e., failure modes.

Tory, E. G.↗

Designing a configuration control mechanism for a flight software validation facility

Embedded computer systems and supporting operating systems have recently enabled the automation of many time-critical flight functions. This automation requires the integration of computer hardware and software, aircraft hardware, and the flight application. To properly integrate and control these critical functions requires a real-time environment that is provided by the onboard flight computer, a real-time operating system, and a real-time flight application that supplies the input commands to the aircraft and responds to the resulting actions. The increased complexity of developing and testing such real-time applications can best be supported by a separate test facility that provides the processing visibility and control which is virtually impossible in the actual real-time operating environment. Such a flight software validation facility has been developed at the NASA Langley Research Center to support applications using the Shuttle real-time language HAL/S. The development and control of this facility are described. Some of the management techniques used were project schedules, status monitoring, code walk-throughs, configuration control, phased releases, validation suites, and modern programming techniques.

Smith-Taylor, R.↗

Imaging Sensor Flight and Test Equipment Software

The Lightning Imaging Sensor (LIS) is one of the components onboard the Tropical Rainfall Measuring Mission (TRMM) satellite, and was designed to detect and locate lightning over the tropics. The LIS flight code was developed to run on a single onboard digital signal processor, and has operated the LIS instrument since 1997 when the TRMM satellite was launched. The software provides controller functions to the LIS Real-Time Event Processor (RTEP) and onboard heaters, collects the lightning event data from the RTEP, compresses and formats the data for downlink to the satellite, collects housekeeping data and formats the data for downlink to the satellite, provides command processing and interface to the spacecraft communications and data bus, and provides watchdog functions for error detection. The Special Test Equipment (STE) software was designed to operate specific test equipment used to support the LIS hardware through development, calibration, qualification, and integration with the TRMM spacecraft. The STE software provides the capability to control instrument activation, commanding (including both data formatting and user interfacing), data collection, decompression, and display and image simulation. The LIS STE code was developed for the DOS operating system in the C programming language. Because of the many unique data formats implemented by the flight instrument, the STE software was required to comprehend the same formats, and translate them for the test operator. The hardware interfaces to the LIS instrument using both commercial and custom computer boards, requiring that the STE code integrate this variety into a working system. In addition, the requirement to provide RTEP test capability dictated the need to provide simulations of background image data with short-duration lightning transients superimposed. This led to the development of unique code used to control the location, intensity, and variation above background for simulated lightning strikes at user-selected locations.

Freestone, Kathleen↗

Delay/Disruption Tolerant Networking for the International Space Station (ISS)

Disruption Tolerant Networking (DTN) is an emerging data networking technology designed to abstract the hardware communication layer from the spacecraft/payload computing resources. DTN is specifically designed to operate in environments where link delays and disruptions are common (e.g., space-based networks). The National Aeronautics and Space Administration (NASA) has demonstrated DTN on several missions, such as the Deep Impact Networking (DINET) experiment, the Earth Observing Mission 1 (EO-1) and the Lunar Laser Communication Demonstration (LLCD). To further the maturation of DTN, NASA is implementing DTN protocols on the International Space Station (ISS). This paper explains the architecture of the ISS DTN network, the operational support for the system, the results from integrated ground testing, and the future work for DTN expansion.

Schlesinger, Adam↗

Real-Time Hardware-in-the-Loop Evaluation of A Partially Turboelectric Propulsion Control Design

In support of aviation fuel burn and emission reduction goals, NASA is pursuing high-payoff research investments that promise to transform aviation. This includes investments in Electrified Aircraft Propulsion (EAP). Multiple technology challenges must be addressed to unlock the full potential of EAP. This includes addressing challenges related to propulsion controls, which will be vital for ensuring efficient coordinated operation of EAP subsystems. This paper presents results from real-time hardware-in-theloop (HIL) testing of a control design for a single aisle partially-turboelectric aircraft propulsion concept conducted at the NASA Electric Aircraft Testbed (NEAT) facility. The control system under test is designed for a propulsion concept consisting of two wing-mounted turbofan engines that produce thrust and generate electrical power to drive a boundary layer ingesting tailfan propulsor via an electrical motor. An integrated control strategy is applied to ensure coordinated operation of the turbofan and tailfan subsystems during steady-state and transient operation throughout the flight envelope. The NEAT test of this integrated control design consists of a partially HIL, partially simulated configuration. A subscale representation of the electrical system design is implemented in hardware and mechanically coupled to electric machines that emulate turbomachinery and propulsor shaft dynamics. The hardware configuration is then operated under the control of a real-time computer application that runs a simulation of the propulsion system and the developed control logic. The NEAT facility test campaign includes a series of experiments that subject the control design to throttle transients conducted throughout the flight envelope and full-flight mission profiles. Testing under simulated performance degradation is also conducted to evaluate control design robustness. This includes constant and abrupt changes in degradation levels. Results from the HIL test are presented and shown to be in good agreement with pretest simulation predictions demonstrating the efficacy of the integrated control design approach.

Electrified Aircraft Propulsion↗

Hardware in the Loop Testing of an Iodine-Fed Hall Thruster

CUBESATS are relatively new spacecraft platforms that are typically deployed from a launch vehicle as a secondary payload,1 providing low-cost access to space for a wide range of end-users. These satellites are comprised of building blocks having dimensions of 10x10x10 cm cu and a mass of 1.33 kg (a 1-U size). While providing low-cost access to space, a major operational limitation is the lack of a propulsion system that can fit within a CubeSat and is capable of executing high delta v maneuvers. This makes it difficult to use CubeSats on missions requiring certain types of maneuvers (i.e. formation flying, spacecraft rendezvous). Recently, work has been performed investigating the use of iodine as a propellant for Hall-effect thrusters (HETs) 2 that could subsequently be used to provide a high specific impulse path to CubeSat propulsion. Iodine stores as a dense solid at very low pressures, making it acceptable as a propellant on a secondary payload. It has exceptionally high ρIsp (density times specific impulse), making it an enabling technology for small satellite near-term applications and providing the potential for systems-level advantages over mid-term high power electric propulsion options. Iodine flow can also be thermally regulated, subliming at relatively low temperature ( less than100 C) to yield I2 vapor at or below 50 torr. At low power, the measured performance of an iodine-fed HET is very similar to that of a state-of-the-art xenon-fed thruster. Just as importantly, the current-voltage discharge characteristics of low power iodine-fed and xenon-fed thrusters are remarkably similar, potentially reducing development and qualifications costs by making it possible to use an already-qualified xenon-HET PPU in an iodine-fed system. Finally, a cold surface can be installed in a vacuum test chamber on which expended iodine propellant can deposit. In addition, the temperature doesn't have to be extremely cold to maintain a low vapor pressure in the vacuum chamber (it is under 10(exp -6) torr at -75 C), making it possible to 'cryopump' the propellant with lower-cost recirculating refrigerant-based systems as opposed to using liquid nitrogen or low temperature gaseous helium cryopanels. In the present paper, we describe testing performed using an iodine-fed 200 W Hall thruster mounted to a thrust stand and operated in conjunction with MSFCs Small Projects Rapid Integration and Test Environment (SPRITE) Portable Hardware In the Loop (PHIL) hardware. This work is performed in support of the iodine satellite (iSAT) project, which aims to fly a 200-W iodine-fed thruster on a 12-U CubeSat. The SPRITE PHIL hardware allows a given vehicle to do a checkout of its avionics algorithm by allowing it to monitor and feed data to simulated sensors and effectors in a digital environment. These data are then used to determine the attitude of the vehicle and a separate computer is used to interpret the data set and visualize it using a 3D graphical interface. The PHIL hardware allows the testing of the vehicles bus by providing 'real' hardware interfaces (in the case of this test a real RS422 bus) and specific components can be modeled to show their interactions with the avionics algorithm (e.g. a thruster model). For the iSAT project the PHIL is used to visualize the operating cycle of the thruster and the subsequent effect this thrusting has on the attitude of the satellite over a given period of time. The test is controlled using software running on an Andrews Space Cortex 160 flight computer. This computer is the current baseline for a full iSAT mission. While the test could be conducted with a lab computer and software, the team chose to exercise the propulsion system with a representative CubeSat-class computer. For purposes of this test, the "flight" software monitored the propulsion and PPU systems, controlled operation of the thruster, and provided thruster state data to the PHIL simulation. Commands to operate the thruster were initiated from an operator's workstation outside the vacuum chamber and passed through the Cortex 160 to exercise portions of the flight avionics. Two custom-designed pieces of electronics hardware have been designed to operate the propellant feed system. One piece of hardware is an auxiliary board that controls a latch valve, proportional flow control valves (PFCVs) and valve heaters as well as measuring pressures, temperatures and PFCV feedback voltage. An onboard FPGA provides a serial link for issuing commands and manages all lower level input-output functions. The other piece of hardware is a power distribution board, which accepts a standard bus voltage input and converts this voltage into all the different current-voltage types required to operate the auxiliary board. These electronics boards are located in the vacuum chamber near the thruster, exposing this hardware to both the vacuum and plasma environments they would encounter during a mission, with these components communicating to the flight computer through an RS-422 interface. The auxiliary board FPGA provides a 28V MOSFET switch circuit with a 20ms pulse to open or close the iodine propellant feed system latch valve. The FPGA provides a pulse width modulation (PWM) signal to a DC/DC boost converter to produce the 12-120V needed for control of the proportional flow control valve. There are eight MOSFET-switched heating circuits in the system. Heaters are 28V and located in the latch valve, PFCV, propellant tank and propellant feed lines. Both the latch valve and PFCV have thermistors built into them for temperature monitoring. There are also seven resistance temperature device (RTD) circuits on the auxiliary board that can be used to measure the propellant tank and feedline temperatures. The signals are conditioned and sent to an analog to digital converter (ADC), which is directly commanded and controlled by the FPGA.

Polzin, Kurt A.↗

Shuttle avionics system

The avionics system of the Space Shuttle is designed in a fail operational/fail safe architecture. The guidance, navigation and control system is implemented, through the onboard Orbiter digital computers. Guidance, navigation and control sensors are triplex, while the flight control effectors are mechanized either in load sharing or quad structure. Two sets of basic flight instruments and controls are provided along with electronic interfaces to allow for multiple selection of input destination and display source selection. Communications, tracking and instrumentation subsystems are mechanized as a dual hardware design for key operational elements. The data processing system allows for quad, triplex, dual or single computer operation. The power distribution subsystem provides a triple bus system with appropriate tie elements. A functional description is given of the computer system, the data bus, the mass memory unit, the multiplexer/demultiplexer and the CRT display system.

Gardiner, R. A.↗

A fast, programmable hardware architecture for spaceborne SAR processing

The launch of spaceborne SARs during the 1980's is discussed. The satellite SARs require high quality and high throughput ground processors. Compression ratios in range and azimuth of greater than 500 and 150 respectively lead to frequency domain processing and data computation rates in excess of 2000 million real operations per second for C-band SARs under consideration. Various hardware architectures are examined and two promising candidates and proceeds to recommend a fast, programmable hardware architecture for spaceborne SAR processing are selected. Modularity and programmability are introduced as desirable attributes for the purpose of HTSP hardware selection.

Bennett, J. R.↗

Mission and data operations IBM 360 user's guide

The M and DO computer systems are introduced and supplemented. The hardware and software status is discussed, along with standard processors and user libraries. Data management techniques are presented, as well as machine independence, debugging facilities, and overlay considerations.

Balakirsky, J.↗

An emulator for minimizing finite element analysis implementation resources

A finite element analysis emulator providing a basis for efficiently establishing an optimum computer implementation strategy when many calculations are involved is described. The SCOPE emulator determines computer resources required as a function of the structural model, structural load-deflection equation characteristics, the storage allocation plan, and computer hardware capabilities. Thereby, it provides data for trading analysis implementation options to arrive at a best strategy. The models contained in SCOPE lead to micro-operation computer counts of each finite element operation as well as overall computer resource cost estimates. Application of SCOPE to the Memphis-Arkansas bridge analysis provides measures of the accuracy of resource assessments. Data indicate that predictions are within 17.3 percent for calculation times and within 3.2 percent for peripheral storage resources for the ELAS code.

Melosh, R. J.↗

Survivable algorithms and redundancy management in NASA's distributed computing systems

The design of survivable algorithms requires a solid foundation for executing them. While hardware techniques for fault-tolerant computing are relatively well understood, fault-tolerant operating systems, as well as fault-tolerant applications (survivable algorithms), are, by contrast, little understood, and much more work in this field is required. We outline some of our work that contributes to the foundation of ultrareliable operating systems and fault-tolerant algorithm design. We introduce our consensus-based framework for fault-tolerant system design. This is followed by a description of a hierarchical partitioning method for efficient consensus. A scheduler for redundancy management is introduced, and application-specific fault tolerance is described. We give an overview of our hybrid algorithm technique, which is an alternative to the formal approach given.

Malek, Miroslaw↗

Color matrix display simulation based upon luminance and chromatic contrast sensitivity of early vision

This paper describes the design and operation of a new simulation model for color matrix display development. It models the physical structure, the signal processing, and the visual perception of static displays, to allow optimization of display design parameters through image quality measures. The model is simple, implemented in the Mathematica computer language, and highly modular. Signal processing modules operate on the original image. The hardware modules describe backlights and filters, the pixel shape, and the tiling of the pixels over the display. Small regions of the displayed image can be visualized on a CRT. Visual perception modules assume static foveal images. The image is converted into cone catches and then into luminance, red-green, and blue-yellow images. A Haar transform pyramid separates the three images into spatial frequency and direction-specific channels. The channels are scaled by weights taken from human contrast sensitivity measurements of chromatic and luminance mechanisms at similar frequencies and orientations. Each channel provides a detectability measure. These measures allow the comparison of images displayed on prospective devices and, by that, the optimization of display designs.

Martin, Russel A.↗

DUKSUP: A Computer Program for High Thrust Launch Vehicle Trajectory Design and Optimization

From the late 1960's through 1997, the leadership of NASA's Intermediate and Large class unmanned expendable launch vehicle projects resided at the NASA Lewis (now Glenn) Research Center (LeRC). One of LeRC's primary responsibilities --- trajectory design and performance analysis --- was accomplished by an internally-developed analytic three dimensional computer program called DUKSUP. Because of its Calculus of Variations-based optimization routine, this code was generally more capable of finding optimal solutions than its contemporaries. A derivation of optimal control using the Calculus of Variations is summarized including transversality, intermediate, and final conditions. The two point boundary value problem is explained. A brief summary of the code's operation is provided, including iteration via the Newton-Raphson scheme and integration of variational and motion equations via a 4th order Runge-Kutta scheme. Main subroutines are discussed. The history of the LeRC trajectory design efforts in the early 1960's is explained within the context of supporting the Centaur upper stage program. How the code was constructed based on the operation of the Atlas/Centaur launch vehicle, the limits of the computers of that era, the limits of the computer programming languages, and the missions it supported are discussed. The vehicles DUKSUP supported (Atlas/Centaur, Titan/Centaur, and Shuttle/Centaur) are briefly described. The types of missions, including Earth orbital and interplanetary, are described. The roles of flight constraints and their impact on launch operations are detailed (such as jettisoning hardware on heating, Range Safety, ground station tracking, and elliptical parking orbits). The computer main frames on which the code was hosted are described. The applications of the code are detailed, including independent check of contractor analysis, benchmarking, leading edge analysis, and vehicle performance improvement assessments. Several of DUKSUP's many major impacts on launches are discussed including Intelsat, Voyager, Pioneer Venus, HEAO, Galileo, and Cassini.

high thrust trajectory design↗