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 145 records · Page 8
All sourcesNASA NTRSDOE OSTI
NASA NTRS1989

A real time microcomputer implementation of sensor failure detection for turbofan engines

An algorithm was developed which detects, isolates, and accommodates sensor failures using analytical redundancy. The performance of this algorithm was demonstrated on a full-scale F100 turbofan engine. The algorithm was implemented in real-time on a microprocessor-based controls computer which includes parallel processing and high order language programming. Parallel processing was used to achieve the required computational power for the real-time implementation. High order language programming was used in order to reduce the programming and maintenance costs of the algorithm implementation software. The sensor failure algorithm was combined with an existing multivariable control algorithm to give a complete control implementation with sensor analytical redundancy. The real-time microprocessor implementation of the algorithm which resulted in the successful completion of the algorithm engine demonstration, is described.

Delaat, John C.↗
NASA NTRS1990

A real time microcomputer implementation of sensor failure detection for turbofan engines

An algorithm was developed that detects, isolates, and accommodates sensor failures using analytical redundancy. The performance of this algorithm has been demonstrated on a full-scale F100 turbofan engine. The algorithm was implemented in real-time on a microprocessor-based controls computer which includes parallel processing and high order language programming. Parallel processing was used to achieve the required computational power for the real-time implementation. High order language programming was used in order to reduce the programming and maintenance costs of the algorithm implementation software. The sensor failure algorithm was combined with an existing multivariable control algorithm to give a complete control implementation with sensor analytical redundancy. The real-time microprocessor implementation of the algorithm, which resulted in the successful completion of the algorithm engine demonstration, is described.

Delaat, John C.↗
NASA NTRS1995

Probabilistic Fatigue And Flaw-Propagation Analysis

Probabilistic Failure Assessment for Fatigue and Flaw Propagation (PFAFAT II) package of software utilizing probabilistic failure-assessment (PFA) methodology to model flaw-propagation and low-cycle-fatigue modes of failure of structural components. Comprises one program for performing probabilistic crack-growth analysis and two programs for performing probabilistic low-cycle-fatigue analysis. These programs perform probabilistic fatigue and crack-propagation analysis by means of Monte Carlo simulation. PFAFAT II is extension of, rather than replacement for, PFAFAT software (NPO-18965). Written in FORTRAN 77.

Moore, Nicholas↗
NASA NTRS2022

Reliability-Aware Requirements Development for Autonomy Software

Autonomy is the ability of a system to make decisions and take actions in the presence of uncertainty. Validating autonomy, therefore, is a matter of validating that the system makes intelligent decisions even when there might be discrepancies between the observed and the expected state of the world as well as when the possible outcome of each of the possible courses of action is uncertain. During the requirements engineering phase, the functions, including those that are required to be autonomous and their expected behavior are specified. However, in the case of autonomous software system, it is challenging to specify all possible scenarios that the software may encounter. Additionally, since autonomous behaviors cannot always be fully predetermined, it is difficult to reason about their completeness and correctness. While these challenges are also faced with non-autonomous system, they are more prevalent for autonomous system due to their complexity and emergent behavior. Our efforts have been three-fold. On one hand, we have developed a goal-based method for requirements decomposition. We have embedded this approach into a higher-level systems engineering framework and then developed methods for decision and reliability analysis within this framework. And finally, we use simulation analysis to validate the more theoretical methods and provide a feedback mechanism. The decision analysis approach (DA) helps in identifying and mitigating the run-time risks, by bringing to the forefront the uncertainties, decisions, interactions, and other factors that may cause autonomous software to make erroneous decisions. The DA framework is used to quantify, for each decision that the software can make, failure risk due to uncertainties. The information about the key decisions and circumstances that can cause autonomous system to make incorrect decisions are used to generate test scenarios to be run in a simulator to ensure that the system can handle error-prone circumstances. The results or outcomes from decisions, based on the simulated scenarios, can then be leveraged to further gain insight of the assured system. We combine a goal-based approach with simulation analysis to facilitate requirements development for autonomous systems and further provide a method for run-time systems level reliability considerations during the autonomous software development process. The DA and the reliability analysis methods provide a formalism for the consideration of uncertainty in the run time decision-making process for autonomous software. This formalism considers the uncertainty involved in the outcome of different courses of action, in terms of performance and cost, as well as a method to consider the system level reliability implications. System level reliability considerations for autonomous software decision making contribute to the satisfaction of the system level goals over the lifecycle of a given mission. We demonstrate our approach using a hypothetical rover path planning example. The requirements for our rover simulator are based on existing literature about Mars rovers and lessons learned from real world observations at JPL. The specifics of the autonomy design for the Mars rovers, that have not been previously cleared for external release, are not used for our demonstrations.

Lindvall, Mikael↗
NASA NTRS1980

Orbiter subsystem hardware/software interaction analysis. Volume 8: AFT reaction control system, part 2

The orbiter subsystems and interfacing program elements which interact with the orbiter computer flight software are analyzed. The failure modes identified in the subsystem/element failure mode and effects analysis are examined. Potential interaction with the software is examined through an evaluation of the software requirements. The analysis is restricted to flight software requirements and excludes utility/checkout software. The results of the hardware/software interaction analysis for the forward reaction control system are presented.

Becker, D. D.↗
NASA NTRS2011

Health Monitor for Multitasking, Safety-Critical, Real-Time Software

Health Manager can detect Bad Health prior to a failure occurring by periodically monitoring the application software by looking for code corruption errors, and sanity-checking each critical data value prior to use. A processor s memory can fail and corrupt the software, or the software can accidentally write to the wrong address and overwrite the executing software. This innovation will continuously calculate a checksum of the software load to detect corrupted code. This will allow a system to detect a failure before it happens. This innovation monitors each software task (thread) so that if any task reports "bad health," or does not report to the Health Manager, the system is declared bad. The Health Manager reports overall system health to the outside world by outputting a square wave signal. If the square wave stops, this indicates that system health is bad or hung and cannot report. Either way, "bad health" can be detected, whether caused by an error, corrupted data, or a hung processor. A separate Health Monitor Task is started and run periodically in a loop that starts and stops pending on a semaphore. Each monitored task registers with the Health Manager, which maintains a count for the task. The registering task must indicate if it will run more or less often than the Health Manager. If the task runs more often than the Health Manager, the monitored task calls a health function that increments the count and verifies it did not go over max-count. When the periodic Health Manager runs, it verifies that the count did not go over the max-count and zeroes it. If the task runs less often than the Health Manager, the periodic Health Manager will increment the count. The monitored task zeroes the count, and both the Health Manager and monitored task verify that the count did not go over the max-count.

Zoerner, Roger↗
NASA NTRS1976

Redundant Strapdown Laser Gyro Navigation System

For the last several years, NASA has pursued the development of low-cost high-reliability inertial navigation systems that would satisfy a broad spectrum of future space and avionics missions. Two specific programs have culminated in the construction of a Redundant Strapdown Laser Gyro Navigation System. These two programs were for development of a space ultrareliable modular computer (SUMC) and a redundant laser gyro inertial measurement unit (IMU). The SUMC is a digital computer that employs state-of-the-art large-scale integrated circuits configured in a functional modular breakdown. The redundant laser gyro IMU is a six-pack strapdown sensor package in a dodecahedron configuration which uses six laser gyros to provide incremental angular positions and six accelerometers for linear velocity outputs. The sensor arrangement allows automatic accommodation of two failures; a third failure can be tolerated provided it can be determined. The navigation system also includes redundant power supplies, built-in test-equipment (BITE) circuits for failure detection, and software which provides for navigation, redundancy management, and automatic calibration and alignment.

Mcpherson, B. W.↗
NASA NTRS1982

Galileo spacecraft power distribution and autonomous fault recovery

There is a trend in current spacecraft design to achieve greater fault tolerance through the implemenation of on-board software dedicated to detecting and isolating failures. A combination of hardware and software is utilized in the Galileo power system for autonomous fault recovery. Galileo is a dual-spun spacecraft designed to carry a number of scientific instruments into a series of orbits around the planet Jupiter. In addition to its self-contained scientific payload, it will also carry a probe system which will be separated from the spacecraft some 150 days prior to Jupiter encounter. The Galileo spacecraft is scheduled to be launched in 1985. Attention is given to the power system, the fault protection requirements, and the power fault recovery implementation.

Detwiler, R. C.↗
NASA NTRS1984

Certification of advanced systems

Advanced cockpit systems in helicopters are evaluated in terms of safety certification areas of concern include: (1) power supply system, failure analysis; (2) software control; (3) lightning substantiation; and (4) adequacy of certification regulations.

Swihart, J. D., Jr.↗
NASA NTRS1985

Beyond the sterile cockpit

Consideration is given to some of the negative aspects of the trend toward increased automation of aircraft flight decks. The history of automated devices for navigation, communications and detection on board aircraft is reviewed. Instances of automatic system failure are identified which have led to accidents, and the events surrounding the downing of Korean Airlines Flight 747 are reexamined within the context of a computer-based system failure. Finally, new software and interactive systems to reduce navigational error due to inadequate computer-assisted flight instruction (CAI) are described, with emphasis given to speech processing and intelligent CAI systems.

Wiener, E. L.↗
NASA NTRS1987

Simulation evaluation of the control system command monitoring concept for the NASA V/STOL research aircraft (VSRA)

A control-system monitoring concept is described that has the potential of rapidly detecting computer command failures (hardware or software) in fly-by-wire control systems. The concept has been successfully tested on the NASA Vertical/Short Takeoff and Landing Research Aircraft (VSRA) in the Ames Research Center's Vertical Motion Simulator. The test was particularly stringent, since the VSRA is required to operate in a hazardous environment. The fidelity of the aircraft model used in the simulation was verified by flying both the simulated and actual aircraft in a precision hover task using specially designed targets.

Schroeder, J. A.↗
NASA NTRS1993

NASA trend analysis procedures

This publication is primarily intended for use by NASA personnel engaged in managing or implementing trend analysis programs. 'Trend analysis' refers to the observation of current activity in the context of the past in order to infer the expected level of future activity. NASA trend analysis was divided into 5 categories: problem, performance, supportability, programmatic, and reliability. Problem trend analysis uncovers multiple occurrences of historical hardware or software problems or failures in order to focus future corrective action. Performance trend analysis observes changing levels of real-time or historical flight vehicle performance parameters such as temperatures, pressures, and flow rates as compared to specification or 'safe' limits. Supportability trend analysis assesses the adequacy of the spaceflight logistics system; example indicators are repair-turn-around time and parts stockage levels. Programmatic trend analysis uses quantitative indicators to evaluate the 'health' of NASA programs of all types. Finally, reliability trend analysis attempts to evaluate the growth of system reliability based on a decreasing rate of occurrence of hardware problems over time. Procedures for conducting all five types of trend analysis are provided in this publication, prepared through the joint efforts of the NASA Trend Analysis Working Group.

Source record↗
NASA NTRS2002

Deep Space 1 flight experience: adventures on an ion drive (AAS 02-072)

This paper provides a brief overview of the DSI attitude control subsystem, shares a few lessons-learned, and describes some of the many daunting challenges faced by our tiny flight team during the course of the mission. Special focus will be given to the nuances of flying a spacecraft with ion propulsion, our nick-of-time rewrite of the attitude determination software after the failure of the on-board star tracker in late 1999, and DSl's subsequent successful flyby of comet Borrelly on September 22, 2001.

SEP ion propulsion DS1 flight experience↗
NASA NTRS2013

Practical Application of PRA as an Integrated Design Tool for Space Systems

This paper presents the application of the first comprehensive Probabilistic Risk Assessment (PRA) during the design phase of a joint NASA/NOAA weather satellite program, Geostationary Operational Environmental Satellite Series R (GOES-R). GOES-R is the next generation weather satellite primarily to help understand the weather and help save human lives. PRA has been used at NASA for Human Space Flight for many years. PRA was initially adopted and implemented in the operational phase of manned space flight programs and more recently for the next generation human space systems. Since its first use at NASA, PRA has become recognized throughout the Agency as a method of assessing complex mission risks as part of an overall approach to assuring safety and mission success throughout project lifecycles. PRA is now included as a requirement during the design phase of both NASA next generation manned space vehicles as well as for high priority robotic missions. The influence of PRA on GOES-R design and operation concepts are discussed in detail. The GOES-R PRA is unique at NASA for its early implementation. It also represents a pioneering effort to integrate risks from both Spacecraft (SC) and Ground Segment (GS) to fully assess the probability of achieving mission objectives. PRA analysts were actively involved in system engineering and design engineering to ensure that a comprehensive set of technical risks were correctly identified and properly understood from a design and operations perspective. The analysis included an assessment of SC hardware and software, SC fault management system, GS hardware and software, common cause failures, human error, natural hazards, solar weather and infrastructure (such as network and telecommunications failures, fire). PRA findings directly resulted in design changes to reduce SC risk from micro-meteoroids. PRA results also led to design changes in several SC subsystems, e.g. propulsion, guidance, navigation and control (GNC), communications, mechanisms, and command and data handling (C&DH). The fault tree approach assisted in the development of the fault management system design. Human error analysis, which examined human response to failure, indicated areas where automation could reduce the overall probability of gaps in operation by half. In addition, the PRA brought to light many potential root causes of system disruptions, including earthquakes, inclement weather, solar storms, blackouts and other extreme conditions not considered in the typical reliability and availability analyses. Ultimately the PRA served to identify potential failures that, when mitigated, resulted in a more robust design, as well as to influence the program's concept of operations. The early and active integration of PRA with system and design engineering provided a well-managed approach for risk assessment that increased reliability and availability, optimized lifecyc1e costs, and unified the SC and GS developments.

Kalia, Prince↗
NASA NTRS1993

Failure detection and recovery in the assembly/contingency subsystem

The Assembly/Contingency Subsystem (ACS) is the primary communications link on board the Space Station. Any failure in a component of this system or in the external devices through which it communicates with ground-based systems will isolate the Station. The ACS software design includes a failure management capability (ACFM) that provides protocols for failure detection, isolation, and recovery (FDIR). The the ACFM design requirements as outlined in the current ACS software requirements specification document are reviewed. The activities carried out in this review include: (1) an informal, but thorough, end-to-end failure mode and effects analysis of the proposed software architecture for the ACFM; and (2) a prototype of the ACFM software, implemented as a C program under the UNIX operating system. The purpose of this review is to evaluate the FDIR protocols specified in the ACS design and the specifications themselves in light of their use in implementing the ACFM. The basis of failure detection in the ACFM is the loss of signal between the ground and the Station, which (under the appropriate circumstances) will initiate recovery to restore communications. This recovery involves the reconfiguration of the ACS to either a backup set of components or to a degraded communications mode. The initiation of recovery depends largely on the criticality of the failure mode, which is defined by tables in the ACFM and can be modified to provide a measure of flexibility in recovery procedures.

Gantenbein, Rex E.↗
NASA NTRS1997

Software Design Improvements: Software Quality and the Design and Inspection Process - Part 2

The application of assurance engineering techniques improves the duration of failure-free performance of software. The totality of features and characteristics of a software product are what determine its ability to satisfy customer needs. Software in safety-critical systems is very important to NASA. We follow the System Safety Working Groups definition for system safety software as: 'The optimization of system safety in the design, development, use and maintenance of software and its integration with safety-critical systems in an operational environment. 'If it is not safe, say so' has become our motto. This paper goes over methods that have been used by NASA to make software design improvements by focusing on software quality and the design and inspection process.

Lalli, Vincent R.↗
NASA NTRS1993

STS-55 pad abort: Engine 2011 oxidizer preburner augmented spark igniter check valve leak

The STS-55 initial launch attempt of Columbia (OV102) was terminated on KSC launch pad A March 22, 1993 at 9:51 AM E.S.T. due to violation of an ME-3 (Engine 2011) Launch Commit Criteria (LCC) limit exceedance. The event description and timeline are summarized. Propellant loading was initiated on 22 March, 1993 at 1:15 AM EST. All SSME chill parameters and launch commit criteria (LCC) were nominal. At engine start plus 1.44 seconds, a Failure Identification (FID) was posted against Engine 2011 for exceeding the 50 psia Oxidizer Preburner (OPB) purge pressure redline. The engine was shut down at 1.50 seconds followed by Engines 2034 and 2030. All shut down sequences were nominal and the mission was safely aborted. The OPB purge pressure redline violation and the abort profile/overlay for all three engines are depicted. SSME Avionics hardware and software performed nominally during the incident. A review of vehicle data table (VDT) data and controller software logic revealed no failure indications other than the single FID 013-414, OPB purge pressure redline exceeded. Software logic was executed according to requirements and there was no anomalous controller software operation. Immediately following the abort, a Rocketdyne/NASA failure investigation team was assembled. The team successfully isolated the failure cause to the oxidizer preburner augmented spark igniter purge check valve not being fully closed due to contamination. The source of the contaminant was traced to a cut segment from a rubber O-ring which was used in a fine clean tool during valve production prior to 1992. The valve was apparently contaminated during its fabrication in 1985. The valve had performed acceptably on four previous flights of the engine, and SSME flight history shows 780 combined check valve flights without failure. The failure of an Engine 3 (SSME No. 2011) check valve to close was sensed by onboard engine instruments even though all other engine operations were normal. This resulted in an engine shutdown and safe sequential shutdown of all three engines prior to ignition of the solid boosters.

Source record↗
NASA NTRS1993

STS-51 pad abort. OV103-engine 2033 (ME-2) fuel flowmeter sensor open circuit

The STS-51 initial launch attempt of Discovery (OV-103) was terminated on KSC launch pad 39B on 12 Aug. 1993 at 9:12 AM E.S.T. due to a sensor redundancy failure in the liquid hydrogen system of ME-2 (Engine 2033). The event description and time line are summarized. Propellant loading was initiated on 12 Aug. 1993 at 12:00 AM EST. All space shuttle main engine (SSME) chill parameters and Launch Commit Criteria (LCC) were nominal. At engine start plus 1.34 seconds a Failure Identification (FID) was posted against Engine 2033 for exceeding the 1800 spin intra-channel (A1-A2) Fuel Flowrate sensor channel qualification limit. The engine was shut down at 1.50 seconds followed by Engines 2032 and 2030. All shut down sequences were nominal and the mission was safely aborted. SSME Avionics hardware and software performed nominally during the incident. A review of vehicle data table (VDT) data and controller software logic revealed no failure indications other than the single FID 111-101, Fuel Flowrate Intra-Channel Test Channel A disqualification. Software logic was executed according to requirements and there was no anomalous controller software operation. Immediately following the abort, a Rocketdyne/NASA failure investigation team was assembled. The team successfully isolated the failure cause to an open circuit in a Fuel Flowrate Sensor. This type of failure has occurred eight previous times in ground testing. The sensor had performed acceptably on three previous flights of the engine and SSME flight history shows 684 combined fuel flow rate sensor channel flights without failure. The disqualification of an Engine 2 (SSME No. 2033) Fuel Flowrate sensor channel was a result of an instrumentation failure and not engine performance. All other engine operations were nominal. This disqualification resulted in an engine shutdown and safe sequential shutdown of all three engines prior to ignition of the solid boosters.

Source record↗