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 73 records · Page 4

All sources NASA NTRS DOE OSTI

NASA NTRS1988

Archival-System Computer Program

Files stored with various degrees of relative performance. ARCHIVE system provides permanent storage area for files to which infrequent access is required. Routines designed to provide simple mechanism by which users store and retrieve files. User treats ARCHIVE as interface to "black box" where files are stored. There are five ARCHIVE user commands, though ARCHIVE employs standard VMS directives and VAX BACKUP utility program. Special care taken to provide security needed to insure integrity of files over period of years. ARCHIVE written in DEC VAX DCL.

Scott, Peter↗

NASA NTRS1972

Motion simulator study of longitudinal stability requirements for large delta wing transport airplanes during approach and landing with stability augmentation systems failed

A ground-based simulator investigation was conducted in preparation for and correlation with an-flight simulator program. The objective of these studies was to define minimum acceptable levels of static longitudinal stability for landing approach following stability augmentation systems failures. The airworthiness authorities are presently attempting to establish the requirements for civil transports with only the backup flight control system operating. Using a baseline configuration representative of a large delta wing transport, 20 different configurations, many representing negative static margins, were assessed by three research test pilots in 33 hours of piloted operation. Verification of the baseline model to be used in the TIFS experiment was provided by computed and piloted comparisons with a well-validated reference airplane simulation. Pilot comments and ratings are included, as well as preliminary tracking performance and workload data.

Snyder, C. T.↗

NASA NTRS2017

Lessons Learned from OSIRIS-Rex Autonomous Navigation Using Natural Feature Tracking

The Origins, Spectral Interpretation, Resource Identification, Security-Regolith Explorer (Osiris-REx) spacecraft is scheduled to launch in September, 2016 to embark on an asteroid sample return mission. It is expected to rendezvous with the asteroid, Bennu, navigate to the surface, collect a sample (July 20), and return the sample to Earth (September 23). The original mission design called for using one of two Flash Lidar units to provide autonomous navigation to the surface. Following Preliminary design and initial development of the Lidars, reliability issues with the hardware and test program prompted the project to begin development of an alternative navigation technique to be used as a backup to the Lidar. At the critical design review, Natural Feature Tracking (NFT) was added to the mission. NFT is an onboard optical navigation system that compares observed images to a set of asteroid terrain models which are rendered in real-time from a catalog stored in memory on the flight computer. Onboard knowledge of the spacecraft state is then updated by a Kalman filter using the measured residuals between the rendered reference images and the actual observed images. The asteroid terrain models used by NFT are built from a shape model generated from observations collected during earlier phases of the mission and include both terrain shape and albedo information about the asteroid surface. As a result, the success of NFT is highly dependent on selecting a set of topographic features that can be both identified during descent as well as reliably rendered using the shape model data available. During development, the OSIRIS-REx team faced significant challenges in developing a process conducive to robust operation. This was especially true for terrain models to be used as the spacecraft gets close to the asteroid and higher fidelity models are required for reliable image correlation. This paper will present some of the challenges and lessons learned from the development of the NFT system which includes not just the flight hardware and software but the development of the terrain models used to generate the onboard rendered images.

Navigation↗

NASA NTRS1985

Shuttle avionics software development trials: Tribulations and successes, the backup flight system

The development and verification of the Backup Flight System software (BFS) is discussed. The approach taken for the BFS was to develop a very simple and straightforward software program and then test it in every conceivable manner. The result was a program that contained approximately 12,000 full words including ground checkout and the built in test program for the computer. To perform verification, a series of tests was defined using the actual flight type hardware and simulated flight conditions. Then simulated flights were flown and detailed performance analysis was conducted. The intent of most BFS tests was to demonstrate that a stable flightpath could be obtained after engagement from an anomalous initial condition. The extention of the BFS to meet the requirements of the orbital flight test phase is also described.

Chevers, E. S.↗

NASA NTRS1981

Fault-tolerant computer study

A set of building block circuits is described which can be used with commercially available microprocessors and memories to implement fault tolerant distributed computer systems. Each building block circuit is intended for VLSI implementation as a single chip. Several building blocks and associated processor and memory chips form a self checking computer module with self contained input output and interfaces to redundant communications buses. Fault tolerance is achieved by connecting self checking computer modules into a redundant network in which backup buses and computer modules are provided to circumvent failures. The requirements and design methodology which led to the definition of the building block circuits are discussed.

Rennels, D. A.↗

NASA NTRS2017

Trajectory Specification for Terminal Air Traffic: Pairwise Conflict Detection and Resolution

Trajectory Specification is the explicit bounding and control of aircraft trajectories such that the position at any point in time is constrained to a precisely defined volume of space. The bounding space is defined by cross-track, along-track, and vertical tolerances relative to a reference trajectory that specifies position as a function of time. The tolerances are dynamic and will be based on the aircraft navigation capabilities and the current traffic situation. Assuming conformance, Trajectory Specification can guarantee safe separation for an arbitrary period of time even in the event of an air traffic control (ATC) system or datalink failure; hence it can help to achieve the high level of safety and reliability needed for ATC automation. It can also reduce the reliance on tactical backup systems during normal operation. This paper applies it to the terminal area around a major airport and presents algorithms and software for detecting and resolving conflicts. A representative set of pairwise conflicts was generated, and a fast-time simulation was run on them. All conflicts were successfully resolved in real time, demonstrating the computational feasibility of the concept.

terminal area↗

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.↗

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.↗

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↗