SEARCH · Search NASA

Results for “Computer Backup Systems”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 91 records · Page 5

All sources NASA NTRS DOE OSTI

NASA NTRS1988

Explicit modeling and concurrent processing in the simulation of multibody dynamic systems

The objective is to present the activities at TRW in developing the capability to simulate the behavior of large flexible multibody space structures. The features of the simulation tools are: (1) to accommodate all rigid/flexible body degrees-of-freedom which incorporate the control system models and external forces, (2) to provide the flexibility to incorporate engineering-defined models and to retain parameters of significance to the engineer, (3) to reduce the computation cost by one order of magnitude (two orders of magnitude compared to a CRAY 1S), and (4) to keep it versatile so that radical variations in anticipated space structures can be accommodated. The current computer tools to simulate multibody systems appear not only to be very costly and time consuming, but also do not produce the desired fidelity of the mathematical models. In summary, a multibody simulation tool will be developed in the near future which will allow solution of the dynamics and controls of the deployment of the LDR backup structure, or the problem associated with the robotic assembly of the structure. The tools will allow the engineer to define the modeling technique and solve problems in less time and at reduced cost.

Gluck, R.↗

NASA NTRS2016

Thomas Leps Internship Abstract

An optical navigation system is being flown as the backup system to the primary Deep Space Network telemetry for navigation and guidance purposes on Orion. This is required to ensure Orion can recover from a loss of communication, which would simultaneously cause a loss of DSN telemetry. Images taken of the Moon and Earth are used to give range and position information to the navigation computer for trajectory calculations and maneuver execution. To get telemetry data from these images, the size and location of the moon need to be calculated with high accuracy and precision. The reentry envelope for the Orion EM-1 mission requires the centroid and radius of the moon images to be determined within 1/3 of a pixel 3 sigma. In order to ensure this accuracy and precision can be attained, I was tasked with building precise dot grid images for camera calibration as well as building a hardware in the loop test stand for flight software and hardware proofing. To calibrate the Op-Nav camera a dot grid is imaged with the camera, the error between the image dot location and the actual dot location can be used to build a distortion map of the camera and lens system so that images can be fixed to display truth locations. To build the dot grid images I used the Electro Optics Lab optical bench Bright Object Simulator System, and gimbal. The gimbal was slewed to a series of elevations and azimuths. An image of the collimated single point light source was then taken at each position. After a series of 99 images were taken at different locations the single light spots were extracted from each image and added to a composite image containing all 99 points. During the development of these grids it was noticed that an intermittent error in the artificial "star" locations occurred. Prior to the summer this error was attributed to the gimbal having glitches in it's pointing direction and was going to be replaced, however after further examining the issue I determined it to be a software issue. I have since narrowed the likely source of the error down to a Software Development Kit released by the camera supplier PixeLink. I have since developed a workaround in order to build star grids for calibration until the software bug can be isolated and fixed. I was also tasked with building a Hardware in the Loop test stand in order to test the full Op-Nav system. A 4k screen displays simulated Lunar and Terrestrial images from a possible Orion trajectory. These images are then projected through a collimator and then captured with an Op-Nav camera controlled by an Intel NUC computer running flight software. The flight software then analyzes the images to determine attitude and position, this data is then reconstructed into a trajectory and matched to the simulated trajectory in order to determine the accuracy of the attitude and position estimates. In order for the system to work it needs to be precisely and accurately aligned. I developed an alignment procedure that allows the screen, collimator and camera to be squared, centered and collinear with each other within a micron spatially and 5 arcseconds in rotation. I also designed a rigid mount for the screen that was machined on site in Building 10 by another intern. While I was working in the EOL we received a $500k Orion startracker for alignment procedure testing. Due to my prior experience in electronics development, as an ancillary duty, I was tasked with building the cables required to operate and power the startracker. If any errors are made building these cables the startracker would be destroyed, I was honored that the director of the lab entrusted such a critical component with me. This internship has cemented my view on public space exploration. I always preferred public sector to privatization because, as a scientist, the most interesting aspects of space for me are not necessarily the most profitable. I was concerned that the public sector was faltering however, and that in order to improve human space exploration I would be forced into private sector. I now know that, at least at JSC, human spaceflight is still progressing, and exciting work is still being done. I am now actively seeking employment at JSC after I complete my Ph.D and have met with my branch chiefs and mentor to discuss transitioning to a grad Co-op position.

Leps, Thomas↗

DOE OSTI2024

High Performance Computing Peak Shaving for Microreactor Operation

There are multiple nuclear microreactors currently under development that are designed to provide autonomous power for as many as ten or more years without refueling and are designed to power high performance computing (HPC) datacenters. But the load-follow speeds for a nuclear microreactor will be much slower than grid power and slower than the power variance typical of a HPC system. HPC datacenters experience peak power load variance driven by several factors ranging from the operation of cooling systems to remove heat from the servers to supporting a wide range of user application workflows and architectures each with different power signatures. One mechanism to support the limited load-follow of a microreactor is peak shaving where an energy storage mechanism is used to shed peak load and reduce significant power variance. This work explores peak electrical load shaving using uninterruptible power supply (UPS) systems designed for HPC support in the context of peak shaving when operating using a nuclear microreactor with a load-follow limited to 10% of load per minute. Using a self contained HPC datacenter complete with stand-alone cooling system and provisioned with an x86 cluster, an ARM cluster, and a graphics processing unit (GPU) cluster, peak shaving for microreactor operation using the UPS battery backup is explored while running two classes of typical HPC user applications. HPC architecture suitability for microreactor operation under this type of peak shaving is examined.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS1981

SMM attitude control recovery

A description is given of the way in which the Modular Attitude Control System (MACS) onboard computer of the NASA Solar Maximum Mission (SMM) laboratory was reprogrammed, to restore attitude control for the SMM, after fuse failures permanently disabled all three of the MACS primary reaction wheels. Algorithms were developed which provided both a thermal- and power-safe, spin-stabilized mode and three-axis sun pointing, using the damaged primary wheels' backup skew wheel in a momentum-bias control scheme. Magnetic torquing was used in these algorithms for angular momentum vector magnitude and directional control.

Hoffman, H. C.↗

NASA NTRS1989

The Voyager 2 mission to Neptune

Voyager 2 and its twin, Voyager 1, were launched in 1977. Both spacecraft investigated Jupiter's and Saturn's systems. Voyager 2 continued on to fly past Utranus in 1986 and Neptune in 1989, while Voyager 1 headed out of the solar system. The mission at Neptune presented many engineering and scientific challenges. Neptune is about 30 Astronomical Units (AU) from the sun and earth, resulting in extremely low lights levels (nearly 1000 times lower than at earth) and in communication distances of nearly 4.5 billion kilometers. To compensate for the long communication distances, several new techniques were developed. As at Uranus, an onboard backup computer compressed the imaging data. In addition, the data return was further improved by electronically arraying and expanding several receiving antennas. As a result, the data rates from Neptune were about the same as they were from Saturn, even though the distance was three times greater. Several changes were made in the onboard software to optimize Voyager's operations at the very low light levels at Neptune. Finally, to obtain the maximum information from the Neptune encounter, a trajectory was selected which passed within just 5000 kilometers of Neptune's atmosphere, but which also posed several possible environmental hazards.

Haynes, Norman R.↗

DOE OSTI2014

RELAP5-3D Resolution of Known Restart/Backup Issues

The state-of-the-art nuclear reactor system safety analysis computer program developed at the Idaho National Laboratory (INL), RELAP5-3D, continues to adapt to changes in computer hardware and software and to develop to meet the ever-expanding needs of the nuclear industry. To continue at the forefront, code testing must evolve with both code and industry developments, and it must work correctly. To best ensure this, the processes of Software Verification and Validation (V&V) are applied. Verification compares coding against its documented algorithms and equations and compares its calculations against analytical solutions and the method of manufactured solutions. A form of this, sequential verification, checks code specifications against coding only when originally written then applies regression testing which compares code calculations between consecutive updates or versions on a set of test cases to check that the performance does not change. A sequential verification testing system was specially constructed for RELAP5-3D to both detect errors with extreme accuracy and cover all nuclear-plant-relevant code features. Detection is provided through a “verification file” that records double precision sums of key variables. Coverage is provided by a test suite of input decks that exercise code features and capabilities necessary to model a nuclear power plant. A matrix of test features and short-running cases that exercise them is presented. This testing system is used to test base cases (called null testing) as well as restart and backup cases. It can test RELAP5-3D performance in both standalone and coupled (through PVM to other codes) runs. Application of verification testing revealed numerous restart and backup issues in both standalone and couple modes. This document reports the resolution of these issues.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

NASA NTRS1995

Propulsion Controlled Aircraft design and development

This paper describes the design, development, and ground testing of the propulsion controlled aircraft (PCA) flight control system. A backup flight control system which uses only engine thrust, the PCA system utilizes collective and differential thrust changes to steer an aircraft that experiences partial or complete failure of the hydraulically actuated control surfaces. The objective of the program was to investigate, in flight, the throttles-only control capability of the F-15, using manual control, and also an augmented PCA mode in which computer-controlled thrust was used for flight control. The objective included PCA operation in up-and-away flight and, if performance was adequate, a secondary objective to make actual PCA landings. The PCA design began with a feasibility study which evaluated many control law designs. The study was done using off-line control analysis, simulation, and on-line manned flight simulator tests. Control laws, cockpit displays, and cockpit controls were evaluated by NASA test pilots. A flight test baseline configuration was selected based on projected flight performance, applicability to transport and fighter aircraft, and funding costs. During the PCA software and hardware development, the initial design was updated as data became available from throttle-only flight experiments conducted by NASA on the F-15. This information showed basic airframe characteristics that were not observed in the F-15 flight simulator and resulted in several design changes. After the primary objectives of the PCA flight testing were accomplished, additional PCA modes of operation were developed and implemented. The evolution of the PCA system from the initial feasibility study, control law design, simulation, hardware-in-the-loop tests, pilot-in-the-loop tests, and ground tests is presented.

Wells, Edward A.↗

NASA NTRS1977

Life sciences Spacelab Mission Development test 3 (SMD 3) data management report

Development of a permanent data system for SMD tests was studied that would simulate all elements of the shuttle onboard, telemetry, and ground data systems that are involved with spacelab operations. The onboard data system (ODS) and the ground data system (GDS) were utilized. The air-to-ground link was simulated by a hardwired computer-to-computer interface. A patch board system was used on board to select experiment inputs, and the downlink configuration from the ODS was changed by a crew keyboard entry to support each experiment. The ODS provided a CRT display of experiment parameters to enable the crew to monitor experiment performance. An onboard analog system, with recording capability, was installed to handle high rate data and to provide a backup to the digital system. The GDS accomplished engineering unit conversion and limit sensing, and provided realtime parameter display on CRT's in the science monitoring area and the test control area.

Moseley, E. C.↗

NASA NTRS1988

Control of optical systems

Some of the current and planned activities at the Air Force Systems Command in structures and controls for optical-type systems are summarized. Many of the activities are contracted to industry; one task is an in-house program which includes a hardware test program. The objective of the in-house program, referred to as the Aluminum Beam Expander Structure (ABES), is to address issues involved in on-orbit system identification. The structure, which appears similar to the LDR backup structure, is about 35 feet tall. The activity to date has been limited to acquisition of about 250 hours of test data. About 30 hours of data per excitation force is gathered in order to obtain sufficient data for a good statistical estimate of the structural parameters. The development of an Integrated Structural Modeling (ISM) computer program is being done by Boeing Aerospace Company. The objective of the contracted effort is to develop a combined optics, structures, thermal, controls, and multibody dynamics simulation code.

Founds, D.↗

NASA NTRS1979

The NASA Multimission Spacecraft Modular Attitude Control System

This paper describes the design of the Modular Attitude Control Subsystem (MACS) that is incorporated in the NASA Multimission Modular Spacecraft (MMS). The MACS is required to provide precision attitude control for a wide class of spacecraft missions including earth pointing, stellar pointing and solar pointing. The MACS is composed of sensors, actuators and associated electronics. Normally the MACS computational, logic and sequencing functions are performed by an Onboard Computer (OBC) located in the MMS; however, the MACS implements an independent backup safe hold attitude controller to protect against the consequences of an OBC failure. The contents of the paper include a description of the MACS configuration and functional operation. The MACS operational modes and performance requirements are described followed by a discussion of the MACS component characteristics. The paper concludes with a description of the safe hold controller design and typical MACS OBC algorithms.

Murrell, J. W.↗

NASA NTRS2013

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗

NASA NTRS2011

Wallops Ship Surveillance System

Approved as a Wallops control center backup system, the Wallops Ship Surveillance Software is a day-of-launch risk analysis tool for spaceport activities. The system calculates impact probabilities and displays ship locations relative to boundary lines. It enables rapid analysis of possible flight paths to preclude the need to cancel launches and allow execution of launches in a timely manner. Its design is based on low-cost, large-customer- base elements including personal computers, the Windows operating system, C/C++ object-oriented software, and network interfaces. In conformance with the NASA software safety standard, the system is designed to ensure that it does not falsely report a safe-for-launch condition. To improve the current ship surveillance method, the system is designed to prevent delay of launch under a safe-for-launch condition. A single workstation is designated the controller of the official ship information and the official risk analysis. Copies of this information are shared with other networked workstations. The program design is divided into five subsystems areas: 1. Communication Link -- threads that control the networking of workstations; 2. Contact List -- a thread that controls a list of protected item (ocean vessel) information; 3. Hazard List -- threads that control a list of hazardous item (debris) information and associated risk calculation information; 4. Display -- threads that control operator inputs and screen display outputs; and 5. Archive -- a thread that controls archive file read and write access. Currently, most of the hazard list thread and parts of other threads are being reused as part of a new ship surveillance system, under the SureTrak project.

Smith, Donna C.↗

DOE OSTI2020

Advanced High-Performance Computational Modeling of the Seismic Response of High-Hazard and/or Nuclear Facilities and Critical Infrastructure at the NNSS

New methods for predicting the amplitude and variability of ground shaking from earthquakes (and explosions) are needed for seismic hazard analysis for buildings, nuclear power plants, and critical infrastructure at the NNSS. We are comparing existing 1-D and new 3-D geophysical methods for estimating the shear-wave velocity structure in the upper 30 meters of the ground surface (Vs30), which plays a major role in ground motion amplification and seismic response of buildings. We evaluate the performance of these methodologies at the U1a Complex at the NNSS and develop simple 1-D and high-resolution 3-D Vs30 models. We then emplace these high-resolution models into a background seismic velocity model. We will collaborate with Lawrence Livermore National Laboratory (LLNL) to conduct numerical modeling of the ground shaking at the NNSS using their high-performance computing technology and state-of-the-art ground motion simulation methodology. The primary work that was completed in FY 2019 was to acquire the seismic systems and familiarize staff at the NNSS with their use. We also worked on developing a collection plan with the Device Assembly Facility (DAF) at the NNSS, but due to time constraints and other ongoing projects at the DAF, we had to use U1a as a backup. We were able to coordinate the seismic survey, and we will complete the collection of seismic data in FY 2020. Additionally, during FY 2019, we completed the geologic framework model (GFM) for the U1a Complex and modeled the Yucca fault. LLNL worked with us through FY 2019 to prepare the data files for their modeling software and tested the software for reliability. In FY 2020 we will develop the end-to-end capability so that any facility could easily be modeled and the expected shaking from a local earthquake understood. The work in FY 2020 will include building fault models from the GFM and finalizing the velocity model analysis. The final simulations will be run for multiple rupture models, and final assessments will demonstrate the seismic hazard at the U1a Complex.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

NASA NTRS2022

Trajectory Specification Applied to Terminal Airspace

Despite major efforts to automate air traffic control (ATC), it is still performed by humans today. The complexity and safety-criticality of ATC makes it very difficult to safely automate, but it must be automated to increase airspace capacity (the density of traffic that can be safely managed) and airport throughput (the number of arrivals and departures that an airport can safely handle in a given period of time) beyond what is possible with human controllers. This paper presents the Trajectory Specification (TS) concept, which can help to safely automate ATC. TS is a method of specifying aircraft trajectories such that the position at any given time in flight is restricted to a precisely defined bounding space, removing all ambiguity as to where the flight is allowed to be. The bounding space or volume is determined by tolerances relative to a reference trajectory (position as a function of time). The tolerances are dynamic and are based on the aircraft navigation capabilities and the traffic situation. The tolerances can be a piecewise linear function of time or distance along the route, allowing the tolerances to vary as needed, typically increasing with time for departures and decreasing for arrivals. A Trajectory Specification Language (TSL) is proposed for communicating trajectories from aircraft to ATC as requests and from ATC to aircraft as assignments. The TS concept requires a new generation of airborne Flight Management Systems (FMS) that understand the TSL and can fly the assigned trajectories, but this paper focuses on the ATC functions and the prototype ATC algorithms and software that were developed to test the TS concept. Assuming conformance, TS can guarantee safe separation for an arbitrary length of time even in the event of an ATC system or communication outage. It can help to achieve the high level of safety and reliability needed for ATC automation, and it can also reduce the reliance on ATC backup systems for tactical conflict detection and resolution during normal operation. TS can be applied to any controlled airspace, including enroute, terminal, and urban airspace, but this paper presents algorithms and software for arrival spacing and conflict detection and resolution in the terminal airspace serving a major airport. In a fast-time simulation of a full day of traffic in a major terminal airspace, all conflicts were resolved in near real time, demonstrating the computational feasibility and the preliminary operational feasibility of the TS concept. This paper is a compilation of previous papers, and it adds significant information that was omitted from those papers due to length limitations. It also updates some of the results of those earlier papers due to algorithm refinements and corrections of minor software errors.

air traffic control, trajectory↗

NASA NTRS2000

Computers Take Flight: A History of NASA's Pioneering Digital Fly-By-Wire Project

An overview of the NASA F-8 Fly-by Wire project is presented. The project made two significant contributions to the new technology: (1) a solid design base of techniques that work and those that do not, and (2) credible evidence of good flying qualities and the ability of such a system to tolerate real faults and to continue operation without degradation. In 1972 the F-8C aircraft used in the program became he first digital fly-by-wire aircraft to operate without a mechanical backup system.

Tomayko, James E.↗

NASA NTRS1978

Fault-tolerant building-block computer study

Ultra-reliable core computers are required for improving the reliability of complex military systems. Such computers can provide reliable fault diagnosis, failure circumvention, and, in some cases serve as an automated repairman for their host systems. A small set of building-block circuits which can be implemented as single very large integration devices, and which can be used with off-the-shelf microprocessors and memories to build self checking computer modules (SCCM) is described. Each SCCM is a microcomputer which is capable of detecting its own faults during normal operation and is described to communicate with other identical modules over one or more Mil Standard 1553A buses. Several SCCMs can be connected into a network with backup spares to provide fault-tolerant operation, i.e. automated recovery from faults. Alternative fault-tolerant SCCM configurations are discussed along with the cost and reliability associated with their implementation.

Rennels, D. A.↗

NASA NTRS2011

Two-Dimensional Finite Element Ablative Thermal Response Analysis of an Arcjet Stagnation Test

The finite element ablation and thermal response (FEAtR, hence forth called FEAR) design and analysis program simulates the one, two, or three-dimensional ablation, internal heat conduction, thermal decomposition, and pyrolysis gas flow of thermal protection system materials. As part of a code validation study, two-dimensional axisymmetric results from FEAR are compared to thermal response data obtained from an arc-jet stagnation test in this paper. The results from FEAR are also compared to the two-dimensional axisymmetric computations from the two-dimensional implicit thermal response and ablation program under the same arcjet conditions. The ablating material being used in this arcjet test is phenolic impregnated carbon ablator with an LI-2200 insulator as backup material. The test is performed at the NASA, Ames Research Center Interaction Heating Facility. Spatially distributed computational fluid dynamics solutions for the flow field around the test article are used for the surface boundary conditions.

Dec, John A.↗

NASA NTRS2005

Harnessing the Power of the Sun

The Environmental Research Aircraft and Sensor Technology (ERAST) Alliance was created in 1994 and operated for 9 years as a NASA-sponsored coalition of 28 members from small companies, government, universities, and nonprofit organizations. ERAST s goal was to foster development of remotely piloted aircraft technology for scientific, humanitarian, and commercial purposes. Some of the aircraft in the ERAST Alliance were intended to fly unmanned at high altitudes for days at a time, and flying for such durations required alternative sources of power that did not add weight. The most successful solution for this type of sustained flight is the lightest solar energy. Photovoltaic cells convert sunlight directly into electricity. They are made of semi-conducting materials similar to those used in computer chips. When sunlight is absorbed, electrons are knocked loose from their atoms, allowing electricity to flow. Under the ERAST Alliance, two solar-powered technology demonstration aircraft, Pathfinder and Helios, were developed. Pathfinder is a lightweight, remotely piloted flying wing aircraft that demonstrated the technology of applying solar cells for long-duration, high-altitude flight. Solar arrays covering most of the upper wing surface provide power for the aircraft s electric motors, avionics, communications, and other electronic systems. Pathfinder also has a backup battery system that can provide power for between 2 and 5 hours to allow limited-duration flight after dark. It was designed, built, and operated by AeroVironment, Inc., of Monrovia, California. On September 11, 1995, Pathfinder reached an altitude of 50,500 feet, setting a new altitude record for solar-powered aircraft. The National Aeronautic Association presented the NASA-industry team with an award for 1 of the 10 Most Memorable Record Flights of 1995.

Source record↗