Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software errors”

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

Detection and avoidance of errors in computer software

The acceptance test errors of a computer software project to determine if the errors could be detected or avoided in earlier phases of development. GROAGSS (Gamma Ray Observatory Attitude Ground Support System) was selected as the software project to be examined. The development of the software followed the standard Flight Dynamics Software Development methods. GROAGSS was developed between August 1985 and April 1989. The project is approximately 250,000 lines of code of which approximately 43,000 lines are reused from previous projects. GROAGSS had a total of 1715 Change Report Forms (CRFs) submitted during the entire development and testing. These changes contained 936 errors. Of these 936 errors, 374 were found during the acceptance testing. These acceptance test errors were first categorized into methods of avoidance including: more clearly written requirements; detail review; code reading; structural unit testing; and functional system integration testing. The errors were later broken down in terms of effort to detect and correct, class of error, and probability that the prescribed detection method would be successful. These determinations were based on Software Engineering Laboratory (SEL) documents and interviews with the project programmers. A summary of the results of the categorizations is presented. The number of programming errors at the beginning of acceptance testing can be significantly reduced. The results of the existing development methodology are examined for ways of improvements. A basis is provided for the definition is a new development/testing paradigm. Monitoring of the new scheme will objectively determine its effectiveness on avoiding and detecting errors.

Kinsler, Les↗
NASA NTRS1989

Error-Free Software

001 is an integrated tool suited for automatically developing ultra reliable models, simulations and software systems. Developed and marketed by Hamilton Technologies, Inc. (HTI), it has been applied in engineering, manufacturing, banking and software tools development. The software provides the ability to simplify the complex. A system developed with 001 can be a prototype or fully developed with production quality code. It is free of interface errors, consistent, logically complete and has no data or control flow errors. Systems can be designed, developed and maintained with maximum productivity. Margaret Hamilton, President of Hamilton Technologies, also directed the research and development of USE.IT, an earlier product which was the first computer aided software engineering product in the industry to concentrate on automatically supporting the development of an ultrareliable system throughout its life cycle. Both products originated in NASA technology developed under a Johnson Space Center contract.

Source record↗
NASA NTRS2001

Report on Automated Semantic Analysis of Scientific and Engineering Codes

The loss of the Mars Climate Orbiter due to a software error reveals what insiders know: software development is difficult and risky because, in part, current practices do not readily handle the complex details of software. Yet, for scientific software development the MCO mishap represents the tip of the iceberg; few errors are so public, and many errors are avoided with a combination of expertise, care, and testing during development and modification. Further, this effort consumes valuable time and resources even when hardware costs and execution time continually decrease. Software development could use better tools! This lack of tools has motivated the semantic analysis work explained in this report. However, this work has a distinguishing emphasis; the tool focuses on automated recognition of the fundamental mathematical and physical meaning of scientific code. Further, its comprehension is measured by quantitatively evaluating overall recognition with practical codes. This emphasis is necessary if software errors-like the MCO error-are to be quickly and inexpensively avoided in the future. This report evaluates the progress made with this problem. It presents recommendations, describes the approach, the tool's status, the challenges, related research, and a development strategy.

Stewart. Maark E. M.↗
NASA NTRS1984

Proceedings of the Ninth Annual Software Engineering Workshop

Experiences in measurement, utilization, and evaluation of software methodologies, models, and tools are discussed. NASA's involvement in ever larger and more complex systems, like the space station project, provides a motive for the support of software engineering research and the exchange of ideas in such forums. The topics of current SEL research are software error studies, experiments with software development, and software tools.

Source record↗
NASA NTRS1993

Analysis of a hardware and software fault tolerant processor for critical applications

Computer systems for critical applications must be designed to tolerate software faults as well as hardware faults. A unified approach to tolerating hardware and software faults is characterized by classifying faults in terms of duration (transient or permanent) rather than source (hardware or software). Errors arising from transient faults can be handled through masking or voting, but errors arising from permanent faults require system reconfiguration to bypass the failed component. Most errors which are caused by software faults can be considered transient, in that they are input-dependent. Software faults are triggered by a particular set of inputs. Quantitative dependability analysis of systems which exhibit a unified approach to fault tolerance can be performed by a hierarchical combination of fault tree and Markov models. A methodology for analyzing hardware and software fault tolerant systems is applied to the analysis of a hypothetical system, loosely based on the Fault Tolerant Parallel Processor. The models consider both transient and permanent faults, hardware and software faults, independent and related software faults, automatic recovery, and reconfiguration.

Dugan, Joanne B.↗
NASA NTRS1981

Ruggedized minicomputer hardware and software topics, 1981: Proceedings of the 4th ROLM MIL-SPEC Computer User's Group Conference

Presentations of a conference on the use of ruggedized minicomputers are summarized. The following topics are discussed: (1) the role of minicomputers in the development and/or certification of commercial or military airplanes in both the United States and Europe; (2) generalized software error detection techniques; (3) real time software development tools; (4) a redundancy management research tool for aircraft navigation/flight control sensors; (5) extended memory management techniques using a high order language; and (6) some comments on establishing a system maintenance scheme. Copies of presentation slides are also included.

Source record↗
NASA NTRS1980

Software reliability: A comparison of results obtained from established software reliability models

Two models of the software error detection process are compared, the Jelinski-Moranda model and a Bayes inference model. Simulation techniques are used to generate software related system failure data which is analyzed by both models. Point estimates and confidence limits are compared. It is demonstrated that uncertainty may be considerable for reasonable samples sizes and should be considered in any application of these techniques. The Jelinski-Moranda model is sensitive to the failure of data to follow internal assumptions of the model, often not providing any point estimates, a factor which may limit its usefulness in many real world situations. The Bayes model is shown to respond to the introduction of additional errors in the software correction process, a condition where error counting models such as the Jelinski-Moranda generally fail to converge.

Horn, M. H.↗
NASA NTRS2018

A Prognostic Launch Vehicle Probability of Failure Assessment Methodology for Conceptual Systems Predicated on Human Causal Factors

Create an improved method to calculate reliability of a conceptual launch vehicle system prior to fabrication by using historic data of actual root causes of failures. While failures have unique "proximate causes", there are typically a finite amount of common "root causes". Heretofore launch vehicle reliability evaluation typically hardware-centric statistical analyses, while most root causes of failures are been shown to be human-centric. A method based on human-centric root causes can be used to quantify reliability assessments and focus proposed actions to mitigate problems. Existing methods have been optimistic in their projections of launch vehicle reliability compared to actuals. Hypothesis: reliability of a conceptual launch vehicle can be more accurately evaluated based on a rational, probabilistic approach using past failure assessment teams' findings predicated on human-centric causes."Human Reliability Analysis Methods Selection Guidance for NASA"Chandler F.T., et al., NASA HQ/OSMA study group, July 2006. Outside HRA experts from academia, other federal labs, and the private sector. 50 system reliability methods considered, fourteen selected for further study, four finally selected as best suited for human spaceflight. Probabilistic Risk Analysis (PRA) + Human Reliability Analysis (HRA) enabled incorporating effects and probabilities of human errors. While four down-selected methods deemed appropriate for failure assessment, it did not appear that these methods could be concisely applied to perform major system-wide assessment of probability of failure of a conceptual design without becoming unwieldy."Engineering a Safer World", Detailed, comprehensive study external to NASA Leveson N. G., MIT, 2011.Systems-Theoretic Accident Model and Processes (STAMP). All-encompassing accident model based on systems theory analyzed accidents after they occurred and created approaches to prevent occurrence in developing systems not focused on failure prevention per se, but rather reducing hazards by influencing human behavior through use of constraints, hierarchical control structures, and process models to improve system safetySystem Theoretic Process Analysis (STPA) addresses predictive part of problem (a "hazard analysis"). Includes all causal factors identified in STAMP: "...design errors, software flaws, component interaction accidents, cognitively complex human decision-making errors, and social organizational and management factors contributing to accidents" can guide design process rather than require it to exist before-hand did not appear capable of concise application for system-wide assessment of probability of failure of a conceptual design without becoming unwieldy.

Williams, Craig H.↗
NASA NTRS1985

Concurrent system-level error detection using a watchdog processor

This paper describes the design of a watchdog coprocessor for detecting hardware and software errors. The watchdog executes assertions about the process running on the main computer. Both general purpose an special purpose (used to check systems such as digital signal processors, telephone switching systems, or digital flight controllers) watchdog designs are described. The improvement of error coverage by adding control flow checking facilities is discussed. The implementation of the watchdog as a software process is presented.

Mahmood, A.↗
NASA NTRS2004

Development of Methodology for Programming Autonomous Agents

A brief report discusses the rationale for, and the development of, a methodology for generating computer code for autonomous-agent-based systems. The methodology is characterized as enabling an increase in the reusability of the generated code among and within such systems, thereby making it possible to reduce the time and cost of development of the systems. The methodology is also characterized as enabling reduction of the incidence of those software errors that are attributable to the human failure to anticipate distributed behaviors caused by the software. A major conceptual problem said to be addressed in the development of the methodology was that of how to efficiently describe the interfaces between several layers of agent composition by use of a language that is both familiar to engineers and descriptive enough to describe such interfaces unambivalently

Erol, Kutluhan↗
NASA NTRS1983

Stress testing of digital flight-control system software

A technique for dynamically testing digital flight-control system software on a module-by-module basis is described. Each test module is repetitively executed faster than real-time with an exhaustive input sequence. Outputs of the test module are compared with outputs generated by an alternate, simpler implementation for the same input data. Discrepancies between the two sets of output indicate the possible presence of a software error. The results of an implementation of this technique in the Digital Flight-Control System Software Verification Laboratory are discussed.

Rajan, N.↗
NASA NTRS2002

Automated Code Standard Checker 2002

Coding standards are typically levied on flight software in order to help ensure that the code is testable, maintainable, and modifiable. Visually checking software source against a set of coding standards is time consuming and may be prone to error. Software inspection is typically costly and may require large amounts of highly skilled labor. The objective of this center initiative is to develop an automated method to ensure that mission critical software follows the required coding practices and standards.

Trevino, Luis↗
NASA NTRS1991

Software reliability experiments data analysis and investigation

The objectives are to investigate the fundamental reasons which cause independently developed software programs to fail dependently, and to examine fault tolerant software structures which maximize reliability gain in the presence of such dependent failure behavior. The authors used 20 redundant programs from a software reliability experiment to analyze the software errors causing coincident failures, to compare the reliability of N-version and recovery block structures composed of these programs, and to examine the impact of diversity on software reliability using subpopulations of these programs. The results indicate that both conceptually related and unrelated errors can cause coincident failures and that recovery block structures offer more reliability gain than N-version structures if acceptance checks that fail independently from the software components are available. The authors present a theory of general program checkers that have potential application for acceptance tests.

Walker, J. Leslie↗
NASA NTRS1993

Magellan spacecraft and memory state tracking: Lessons learned, future thoughts

Numerous studies have been dedicated to improving the two main elements of Spacecraft Mission Operations: Command and Telemetry. As a result, not much attention has been given to other tasks that can become tedious, repetitive, and error prone. One such task is Spacecraft and Memory State Tracking, the process by which the status of critical spacecraft components, parameters, and the contents of on-board memory are managed on the ground to maintain knowledge of spacecraft and memory states for future testing, anomaly investigation, and on-board memory reconstruction. The task of Spacecraft and Memory State Tracking has traditionally been a manual task allocated to Mission Operations Procedures. During nominal Mission Operations this job is tedious and error prone. Because the task is not complex and can be accomplished manually, the worth of a sophisticated software tool is often questioned. However, in the event of an anomaly which alters spacecraft components autonomously or a memory anomaly such as a corrupt memory or flight software error, an accurate ground image that can be reconstructed quickly is a priceless commodity. This study explores the process of Spacecraft and Memory State Tracking used by the Magellan Spacecraft Team highlighting its strengths as well as identifying lessons learned during the primary and extended missions, two memory anomalies, and other hardships encountered due to incomplete knowledge of spacecraft states. Ideas for future state tracking tools that require minimal user interaction and are integrated into the Ground Data System will also be discussed.

Bucher, Allen W.↗
NASA NTRS2015

Global Precipitation Measurement Mission Launch and Commissioning

During launch and early operation of the Global Precipitation Measurement (GPM) Mission, the Guidance, Navigation, and Control (GN&C) analysis team encountered four main on-orbit anomalies. These include: (1) unexpected shock from Solar Array deployment, (2) momentum buildup from the Magnetic Torquer Bars (MTBs) phasing errors, (3) transition into Safehold due to albedo induced Course Sun Sensor (CSS) anomaly, and (4) a flight software error that could cause a Safehold transition due to a Star Tracker occultation. This paper will discuss ways GN&C engineers identified the anomalies and tracked down the root causes. Flight data and GN&C on-board models will be shown to illustrate how each of these anomalies were investigated and mitigated before causing any harm to the spacecraft. On May 29, 2014, GPM was handed over to the Mission Flight Operations Team after a successful commissioning period. Currently, GPM is operating nominally on orbit, collecting meaningful scientific data that will significantly improve our understanding of the Earth's climate and water cycle.

Guidance Navigation and Control↗
NASA NTRS2015

Global Precipitation Measurement Mission Launch and Commissioning

During launch and early operation of the Global Precipitation Measurement (GPM) Mission, the Guidance, Navigation and Control (GNC) analysis team encountered four main on orbit anomalies. These include: (1) unexpected shock from Solar Array deployment, (2) momentum buildup from the Magnetic Torquer Bars (MTBs) phasing errors, (3) transition into Safehold due to albedo-induced Course Sun Sensor (CSS) anomaly, and (4) a flight software error that could cause a Safehold transition due to a Star Tracker occultation. This paper will discuss ways GNC engineers identified and tracked down the root causes. Flight data and GNC on board models will be shown to illustrate how each of these anomalies were investigated and mitigated before causing any harm to the spacecraft. On May 29, 2014, GPM was handed over to the Mission Flight Operations Team after a successful commissioning period. Currently, GPM is operating nominally on orbit, collecting meaningful scientific data that will significantly improve our understanding of the Earth's climate and water cycle.

Guidance Navigation and Control↗
NASA NTRS1990

GSC configuration management plan

The tools and methods used for the configuration management of the artifacts (including software and documentation) associated with the Guidance and Control Software (GCS) project are described. The GCS project is part of a software error studies research program. Three implementations of GCS are being produced in order to study the fundamental characteristics of the software failure process. The Code Management System (CMS) is used to track and retrieve versions of the documentation and software. Application of the CMS for this project is described and the numbering scheme is delineated for the versions of the project artifacts.

Withers, B. Edward↗
NASA NTRS2004

Engineering Complex Embedded Systems with State Analysis and the Mission Data System

It has become clear that spacecraft system complexity is reaching a threshold where customary methods of control are no longer affordable or sufficiently reliable. At the heart of this problem are the conventional approaches to systems and software engineering based on subsystem-level functional decomposition, which fail to scale in the tangled web of interactions typically encountered in complex spacecraft designs. Furthermore, there is a fundamental gap between the requirements on software specified by systems engineers and the implementation of these requirements by software engineers. Software engineers must perform the translation of requirements into software code, hoping to accurately capture the systems engineer's understanding of the system behavior, which is not always explicitly specified. This gap opens up the possibility for misinterpretation of the systems engineer s intent, potentially leading to software errors. This problem is addressed by a systems engineering methodology called State Analysis, which provides a process for capturing system and software requirements in the form of explicit models. This paper describes how requirements for complex aerospace systems can be developed using State Analysis and how these requirements inform the design of the system software, using representative spacecraft examples.

mission data systems↗