Search NASA⌕ Search

SEARCH · Search NASA

Results for “software failure”

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 883 records · Page 49
All sourcesNASA NTRSDOE OSTI
NASA NTRS1990

Advanced Information Processing System (AIPS)-based fault tolerant avionics architecture for launch vehicles

An avionics architecture for the advanced launch system (ALS) that uses validated hardware and software building blocks developed under the advanced information processing system program is presented. The AIPS for ALS architecture defined is preliminary, and reliability requirements can be met by the AIPS hardware and software building blocks that are built using the state-of-the-art technology available in the 1992-93 time frame. The level of detail in the architecture definition reflects the level of detail available in the ALS requirements. As the avionics requirements are refined, the architecture can also be refined and defined in greater detail with the help of analysis and simulation tools. A useful methodology is demonstrated for investigating the impact of the avionics suite to the recurring cost of the ALS. It is shown that allowing the vehicle to launch with selected detected failures can potentially reduce the recurring launch costs. A comparative analysis shows that validated fault-tolerant avionics built out of Class B parts can result in lower life-cycle-cost in comparison to simplex avionics built out of Class S parts or other redundant architectures.

Lala, Jaynarayan H.↗
NASA NTRS1994

Baseline tests of an autonomous telerobotic system for assembly of space truss structures

Several proposed space missions include precision reflectors that are larger in diameter than any current or proposed launch vehicle. Most of these reflectors will require a truss structure to accurately position the reflector panels and these reflectors will likely require assembly in orbit. A research program has been conducted at the NASA Langley Research Center to develop the technology required for the robotic assembly of truss structures. The focus of this research has been on hardware concepts, computer software control systems, and operator interfaces necessary to perform supervised autonomous assembly. A special facility was developed and four assembly and disassembly tests of a 102-strut tetrahedral truss have been conducted. The test procedures were developed around traditional 'pick-and-place' robotic techniques that rely on positioning repeatability for successful operation. The data from two of the four tests were evaluated and are presented in this report. All operations in the tests were controlled by predefined sequences stored in a command file, and the operator intervened only when the system paused because of the failure of an actuator command. The tests were successful in identifying potential pitfalls in a telerobotic system, many of which would not have been readily anticipated or incurred through simulation studies. Addressing the total integrated task, instead of bench testing the component parts, forced all aspects of the task to be evaluated. Although the test results indicate that additional developments should be pursued, no problems were encountered that would preclude automated assembly in space as a viable construction method.

Rhodes, Marvin D.↗
NASA NTRS2007

The Operation and Evolution of the Swift X-ray Telescope

The Swift X-ray Telescope (XRT) is a CCD based X-ray telescope designed for localization, spectroscopy and long term light curve monitoring of Gamma-Ray Bursts and their X-ray afterglows. Since the launch of Swift in November 2004, the XRT has undergone significant evolution in the way it is operated. Shortly after launch there was a failure of the thermo-electric cooler on the XRT CCD, which led to the XRT team being required to devise a method of keeping the XRT CCD temperature below 50C utilizing only passive cooling by minimizing the exposure of the XRT radiator to the Earth. We present in this paper an update on how the modeling of this passive cooling method has improved in first -1000 days since the method was devised, and the success rate of this method in day-to-day planning. We also discuss the changes to the operational modes and onboard software of the XRT. These changes include improved rapid data product generation in order to improve speed of rapid Gamma-Ray Burst response and localization to the community; changes to the way XRT observation modes are chosen in order to better fine tune data aquisition to a particular science goal; reduction of "mode switching" caused by the contamination of the CCD by Earth light or high temperature effects.

Kennea, Jamie↗
NASA NTRS1990

ISIS and META projects

The ISIS project has developed a new methodology, virtual synchony, for writing robust distributed software. High performance multicast, large scale applications, and wide area networks are the focus of interest. Several interesting applications that exploit the strengths of ISIS, including an NFS-compatible replicated file system, are being developed. The META project is distributed control in a soft real-time environment incorporating feedback. This domain encompasses examples as diverse as monitoring inventory and consumption on a factory floor, and performing load-balancing on a distributed computing system. One of the first uses of META is for distributed application management: the tasks of configuring a distributed program, dynamically adapting to failures, and monitoring its performance. Recent progress and current plans are reported.

Birman, Kenneth↗
NASA NTRS2001

Models of an In-Situ Propellant Production Plant for Mars Exploration

An in-situ propellant production system (ISPP) is designed to make rocket fuel from chemicals in the Martian atmosphere in order to reduce the amount of materials that would need to be brought from Earth to support Mars missions. We have developed a description of a hypothetical ISPP system that we would like to make available to researchers who are interested in the problem of automatically diagnosing failures in complex NASA systems. This problem description will help researchers to investigate problems of interest to NASA. We would like to make the following material publicly available: (1) a 'common sense' model of an ISPP system; (2) low- and medium-fidelity simulations of the ISPP system written in Microsoft Excel and HCC; and (3) previously published data and diagrams concerning ISPP components. We do not believe there are any export considerations on these materials for the following reasons: (1) These models are not useful for guidance and real time control of vehicles, encrpytion, or any other software purpose categorized under the Export Control Classification Numbers; and (2) The models are very high level and would not by themselves enable real-time control of a real hardware system. The models are at the level of common sense. They capture, for example, that if a heater is turned on an increase in temperature should result(see the attached excerpt). We do not believe there is any commercial value to this material, given the low commercial demand for propellant plants on mars. We have spoken to acting Code IC Division Chief Dan Clancy, and he concurs with our desire to make these materials publicly available via a technical report.

Goodrich, Charlie↗
NASA NTRS2004

Development and Evaluation of Fault-Tolerant Flight Control Systems

The research is concerned with developing a new approach to enhancing fault tolerance of flight control systems. The original motivation for fault-tolerant control comes from the need for safe operation of control elements (e.g. actuators) in the event of hardware failures in high reliability systems. One such example is modem space vehicle subjected to actuator/sensor impairments. A major task in flight control is to revise the control policy to balance impairment detectability and to achieve sufficient robustness. This involves careful selection of types and parameters of the controllers and the impairment detecting filters used. It also involves a decision, upon the identification of some failures, on whether and how a control reconfiguration should take place in order to maintain a certain system performance level. In this project new flight dynamic model under uncertain flight conditions is considered, in which the effects of both ramp and jump faults are reflected. Stabilization algorithms based on neural network and adaptive method are derived. The control algorithms are shown to be effective in dealing with uncertain dynamics due to external disturbances and unpredictable faults. The overall strategy is easy to set up and the computation involved is much less as compared with other strategies. Computer simulation software is developed. A serious of simulation studies have been conducted with varying flight conditions.

Song, Yong D.↗
DOE OSTI2024

Massively scalable workflows for quantum chemistry: BigChem and ChemCloud

Electronic structure theory, i.e., quantum chemistry, is the fundamental building block for many problems in computational chemistry. Here we present a new distributed computing framework (BigChem), which allows for an efficient solution of many quantum chemistry problems in parallel. BigChem is designed to be easily composable and leverages industry-standard middleware (e.g., Celery, RabbitMQ, and Redis) for distributed approaches to large scale problems. BigChem can harness any collection of worker nodes, including ones on cloud providers (such as AWS or Azure), local clusters, or supercomputer centers (and any mixture of these). BigChem builds upon MolSSI packages, such as QCEngine to standardize the operation of numerous computational chemistry programs, demonstrated here with Psi4, xtb, geomeTRIC, and TeraChem. BigChem delivers full utilization of compute resources at scale, offers a programable canvas for designing sophisticated quantum chemistry workflows, and is fault tolerant to node failures and network disruptions. We demonstrate linear scalability of BigChem running computational chemistry workloads on up to 125 GPUs. Finally, we present ChemCloud, a web API to BigChem and successor to TeraChem Cloud. ChemCloud delivers scalable and secure access to BigChem over the Internet.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗
NASA NTRS1983

Synchronization and fault-masking in redundant real-time systems

A real time computer may fail because of massive component failures or not responding quickly enough to satisfy real time requirements. An increase in redundancy - a conventional means of improving reliability - can improve the former but can - in some cases - degrade the latter considerably due to the overhead associated with redundancy management, namely the time delay resulting from synchronization and voting/interactive consistency techniques. The implications of synchronization and voting/interactive consistency algorithms in N-modular clusters on reliability are considered. All these studies were carried out in the context of real time applications. As a demonstrative example, we have analyzed results from experiments conducted at the NASA Airlab on the Software Implemented Fault Tolerance (SIFT) computer. This analysis has indeed indicated that in most real time applications, it is better to employ hardware synchronization instead of software synchronization and not allow reconfiguration.

Krishna, C. M.↗
NASA NTRS2013

Software Tools to Support the Assessment of System Health

This presentation provides an overview of three software tools that were developed by the NASA Glenn Research Center to support the assessment of system health: the Propulsion Diagnostic Method Evaluation Strategy (ProDIMES), the Systematic Sensor Selection Strategy (S4), and the Extended Testability Analysis (ETA) tool. Originally developed to support specific NASA projects in aeronautics and space, these software tools are currently available to U.S. citizens through the NASA Glenn Software Catalog. The ProDiMES software tool was developed to support a uniform comparison of propulsion gas path diagnostic methods. Methods published in the open literature are typically applied to dissimilar platforms with different levels of complexity. They often address different diagnostic problems and use inconsistent metrics for evaluating performance. As a result, it is difficult to perform a one ]to ]one comparison of the various diagnostic methods. ProDIMES solves this problem by serving as a theme problem to aid in propulsion gas path diagnostic technology development and evaluation. The overall goal is to provide a tool that will serve as an industry standard, and will truly facilitate the development and evaluation of significant Engine Health Management (EHM) capabilities. ProDiMES has been developed under a collaborative project of The Technical Cooperation Program (TTCP) based on feedback provided by individuals within the aircraft engine health management community. The S4 software tool provides a framework that supports the optimal selection of sensors for health management assessments. S4 is structured to accommodate user ]defined applications, diagnostic systems, search techniques, and system requirements/constraints. One or more sensor suites that maximize this performance while meeting other user ]defined system requirements that are presumed to exist. S4 provides a systematic approach for evaluating combinations of sensors to determine the set or sets of sensors that optimally meet the performance goals and the constraints. It identifies optimal sensor suite solutions by utilizing a merit (i.e., cost) function with one of several available optimization approaches. As part of its analysis, S4 can expose fault conditions that are difficult to diagnose due to an incomplete diagnostic philosophy and/or a lack of sensors. S4 was originally developed and applied to liquid rocket engines. It was subsequently used to study the optimized selection of sensors for a simulation ]based aircraft engine diagnostic system. The ETA Tool is a software ]based analysis tool that augments the testability analysis and reporting capabilities of a commercial ]off ]the ]shelf (COTS) package. An initial diagnostic assessment is performed by the COTS software using a user ]developed, qualitative, directed ]graph model of the system being analyzed. The ETA Tool accesses system design information captured within the model and the associated testability analysis output to create a series of six reports for various system engineering needs. These reports are highlighted in the presentation. The ETA Tool was developed by NASA to support the verification of fault management requirements early in the Launch Vehicle process. Due to their early development during the design process, the TEAMS ]based diagnostic model and the ETA Tool were able to positively influence the system design by highlighting gaps in failure detection, fault isolation, and failure recovery.

Melcher, Kevin J.↗
NASA NTRS1984

On-orbit maintenance and repair - New era in space research and industrialization

During the seventies, NASA was developing a multifunction, economical spacecraft complete with ground and spaceborne support equipment, software, and necessary documentation to facilitate a large variety of space missions on a routine and cost effective basis. In order to reduce costs and time requirements, research was conducted to identify new approaches to a reusable, low-cost spacecraft design. The result of these studies was the development of the Multimission Modular Spacecraft (MMS). Three MMS spacecraft are currently operating in orbit. These spacecraft include the two Landsat-D earth resources satellites, Landsat-4 and -5, and the Solar Maximum Mission (SMM) spacecraft. Attention is given to details regarding the MMS, the STS-41C SMM repair mission, and failure modes and component degradation.

Cepollina, F.↗
NASA NTRS1975

Flight Performance of Skylab Attitude and Pointing Control System

In 1967 a paper at the AIAA Guidance, Control and Flight Dynamics Conference in Huntsville, Ala. presented for the first time the prot)osed SKYLAB Attitude and Pointing Control System (APCS) The system requirements, Apollo Telescope Mount (ATM) configuration, control philosophy, and operational modes were presented and the APCS described. The Initial mission and system design requirements changed during the period of time before the SKYLAB was launched. This paper will review the Initial and final APCS requirements and goals and their relationship. The actual flight mission (and Its alterations during the flight) and known achieved APCS performance will then be presented. SKYLAB was a tremendous success in furthering man's scientific knowledge; but perhaps SKYLAB will be remembered more for the anomalies and the efforts undertaken to solve them. On May 14, 1973, the unmanned SKYLAB Orbital Workshop (OWS) was launched from Cape Kennedy. Serious hardware failures began to occur during ascent through the atmosphere and their spectre continued to haunt both the astronauts and their ground based support team. Nor were these the only surprises affecting the design and operation of the APCS. Mission requirements for pointing to various stellar targets and to nadir for earth resources experiments were added after the hardware was designed. The chance appearance of comet Kohoutek during the SKYLAB operational life-time caused NASA to add comet observation to the mission requirements and to adjust the time when the third crew would man the SKYLAB. The development of new procedures and software for the opportunity to observe this visitor to our solar system is described.

Chubb, W. B.↗
NASA NTRS1991

Control algorithm implementation for a redundant degree of freedom manipulator

This project's purpose is to develop and implement control algorithms for a kinematically redundant robotic manipulator. The manipulator is being developed concurrently by Odetics Inc., under internal research and development funding. This SBIR contract supports algorithm conception, development, and simulation, as well as software implementation and integration with the manipulator hardware. The Odetics Dexterous Manipulator is a lightweight, high strength, modular manipulator being developed for space and commercial applications. It has seven fully active degrees of freedom, is electrically powered, and is fully operational in 1 G. The manipulator consists of five self-contained modules. These modules join via simple quick-disconnect couplings and self-mating connectors which allow rapid assembly/disassembly for reconfiguration, transport, or servicing. Each joint incorporates a unique drive train design which provides zero backlash operation, is insensitive to wear, and is single fault tolerant to motor or servo amplifier failure. The sensing system is also designed to be single fault tolerant. Although the initial prototype is not space qualified, the design is well-suited to meeting space qualification requirements. The control algorithm design approach is to develop a hierarchical system with well defined access and interfaces at each level. The high level endpoint/configuration control algorithm transforms manipulator endpoint position/orientation commands to joint angle commands, providing task space motion. At the same time, the kinematic redundancy is resolved by controlling the configuration (pose) of the manipulator, using several different optimizing criteria. The center level of the hierarchy servos the joints to their commanded trajectories using both linear feedback and model-based nonlinear control techniques. The lowest control level uses sensed joint torque to close torque servo loops, with the goal of improving the manipulator dynamic behavior. The control algorithms are subjected to a dynamic simulation before implementation.

Cohan, Steve↗
NASA NTRS2007

Reducing a Knowledge-Base Search Space When Data Are Missing

This software addresses the problem of how to efficiently execute a knowledge base in the presence of missing data. Computationally, this is an exponentially expensive operation that without heuristics generates a search space of 1 + 2n possible scenarios, where n is the number of rules in the knowledge base. Even for a knowledge base of the most modest size, say 16 rules, it would produce 65,537 possible scenarios. The purpose of this software is to reduce the complexity of this operation to a more manageable size. The problem that this system solves is to develop an automated approach that can reason in the presence of missing data. This is a meta-reasoning capability that repeatedly calls a diagnostic engine/model to provide prognoses and prognosis tracking. In the big picture, the scenario generator takes as its input the current state of a system, including probabilistic information from Data Forecasting. Using model-based reasoning techniques, it returns an ordered list of fault scenarios that could be generated from the current state, i.e., the plausible future failure modes of the system as it presently stands. The scenario generator models a Potential Fault Scenario (PFS) as a black box, the input of which is a set of states tagged with priorities and the output of which is one or more potential fault scenarios tagged by a confidence factor. The results from the system are used by a model-based diagnostician to predict the future health of the monitored system.

James, Mark↗
DOE OSTI2026

Validation and Verification of Python based Neutron Spectrum Unfolding Software

To validate and verify the python-based code (PySL), designed to replicate the programs used by STAYSL for Beam Correction Factor (BCF) and Self-Shielding Factor (SHIELD), a series of tests were performed. To test BCF a python script was written to generate a random flux history file and both versions of the code processed the data. The test verified matching values up to at least one decimal place, approximately 10,000 tests where run and each one passed. Isotopes began to fail the tests once neutron saturation was reached. To verify this the total time of exposure was varied the isotopes that failed were compared to a list of their half-lives. The test process for SHIELD was very similar but, in this case, the code began by producing an input file with varying thickness and device type/environment for the SHIELD input. The failure condition for this test was if any of the data points for an isotope had a difference above 3%. Approximately 40 of these tests were run and there were only 3 isotopes that had reoccurring failures but only 2% of their points were above the 3% difference. A visual comparison was conducted by plotting the results from both programs. Although the test failed, the differences between their values were minuscule, and the self-shielding factor’s shape was preserved when plotted. Next steps for this project will be validating and verifying the python-based SigPhi code and then reproducing and testing the least squares unfolding performed by STAYSL.

73 - NUCLEAR PHYSICS AND RADIATION PHYSICS↗
NASA NTRS2009

A Method for Determining the Nominal Occular Hazard Zone for Gaussian Beam Laser Rangers with a Firmware Controlled Variable Focal Length

LIDAR systems that maintain a constant beam spot size on a retroreflector in order to increase the accuracy of bearing and ranging data must use a software controlled variable position lens. These systems periodically update the estimated range and set the position of the focusing lens accordingly. In order to precisely calculate the r NOHD for such a system, the software method for setting the variable position lens and gaussian laser propagation can be used to calculate the irradiance at any point given the range estimation. NASA s Space Shuttle LIDAR, called the Trajectory Control Sensor (TCS), uses this configuration. Analytical tools were developed using Excel and VBA to determine the radiant energy to the International Space Station (ISS) crewmembers eyes while viewing the shuttle on approach and departure. Various viewing scenarios are considered including the use of through-the-lens imaging optics and the window transmissivity at the TCS wavelength. The methodology incorporates the TCS system control logic, gaussian laser propagation, potential failure mode end states, and guidance from American National Standard for the Safe Use of Lasers (ANSI Z136.1-2007). This approach can be adapted for laser safety analyses of similar LIDAR systems.

Picco, C. E.↗
NASA NTRS1990

ISIS and META projects

ISIS and META are two distributed systems projects at Cornell University. The ISIS project, has developed a new methodology, virtual synchrony, for writing robust distributed software. This approach is directly supported by the ISIS Toolkit, a programming system that is distributed to over 300 academic and industrial sites. Several interesting applications that exploit the strengths of ISIS, including an NFS-compatible replicated file system, are being developed. The META project, is about distributed control in a soft real time environment incorporating feedback. This domain encompasses examples as diverse as monitoring inventory and consumption on a factory floor and performing load-balancing on a distributed computing system. One of the first uses of META is for distributed application management: the tasks of configuring a distributed program, dynamically adapting to failures, and monitoring its performance. Recent progress and current plans are presented. This approach to distributed computing, a philosophy that is believed to significantly distinguish the work from that of others in the field, is explained.

Birman, Kenneth↗
NASA NTRS2018

Collaborative Systems Engineering in the Ascent Abort-2 Crew Module/Separation Ring Project

Generally speaking, systems engineering (SE) tool-sets face a dilemma balancing power and accessibility. High-powered SE tools (MagicDraw, Cradle, Core, etc.) tend to be specialized and are available only to highly trained Systems Engineers, and/or through the use of a 'back room' developer team making the output products available to the broader team. On the other hand, highly accessible tools (MS Word, Excel, etc.) do not have the power to implement SE in a rigorous manner. NASA has to test all aspects of the new human-rated Orion Multi-Purpose Crew Vehicle spacecraft prior to its first crewed mission. The test program includes uncrewed launch abort flight tests to demonstrate the capability to save the crew in the event that a launch failure occurs. Orion's second abort flight test will be a low-altitude flight test known as "Ascent Abort 2 (AA-2)." This test is currently scheduled to be carried out at Cape Canaveral Air Force Station's Space Launch Complex 46 (SLC-46) in Florida in 2019. NASA's in-house AA-2 Crew Module and Separation Ring (CSR) Team is producing the crew module and separation ring. Operating jointly as both an Advanced Exploration Systems (AES) Project and an Orion Project, the CSR project charter includes development of innovative, streamlined and generally more efficient practices for creation of flight hardware and software. One result of this tasking has been development of a collaborative and data-centric systems engineering environment within the team's shared web environment (Microsoft SharePoint). Through the use of built-in, 'out of the box capabilities' present in MS SharePoint, the CSR Systems Engineering team has created (with some limited developer support) a data-centric architecture for the project's SE implementation, including functional and interface analysis, requirements development and management, risk management, verification planning and management, test results, and end item management. Data elements are linked between data structures so as to define and control relationships between item types, link requirements to parents and children, and link tests to the requirements that they verify. The overall project team integration is increased by also linking SE content to project management content over the project life cycle, including team communication, action items, configuration management, decisional and meeting materials, and life cycle reviews. This presentation will provide an overview of the collaborative SE environment, showing how it provides the power for a number of SE tasks while still providing the accessibility and transparency to allow the full project team to collaborate and succeed. Given the project phase, we'll be able to present a nearly full lifecycle discussion, from concept through verification and approaching delivery.

Systems Engineering environments↗
NASA NTRS1991

Collision avoidance for CTV: Requirements and capabilities

Cargo transfer vehicle (CTV) operations near Space Station Freedom will require positive collision avoidance maneuver (CAM) capability to preclude any change of collision, even in the event of CTV failures. The requirements for CAM are discussed, and the CAM design approach and design of the Orbiting Maneuvering Vehicle (OMV) are reviewed; this design met requirements for OMV operation near the Space Station, provided a redundant collision avoidance maneuver capability. Significant portions of the OMV CAM design should be applicable to CTV. The key features of the OMV design are summarized and related to the CTV mission design to that of OMV's. CAM is a defined sequence of events executed by the CTV to place the vehicle in a safe position relative to a target such as the Space Station. CAM can be performed through software commands to the propulsion system, or through commands pre-stored in hardware. Various techniques for triggering CAM are considered, and the risks associated with CAM enable and execution in phases are considered. OMV CAM design features both hardware and software CAM capability, with analyses conducted to assess the ability to meet the collision-free requirement during all phases of the mission.

Nosek, Thomas P.↗