Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software Safety”

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 NTRS2007

Testing for Software Safety

This research focuses on testing whether or not the hazardous conditions identified by design-level fault tree analysis will occur in the target implementation. Part 1: Integrate fault tree models into functional specifications so as to identify testable interactions between intended behaviors and hazardous conditions. Part 2: Develop a test generator that produces not only functional tests but also safety tests for a target implementation in a cost-effective way. Part 3: Develop a testing environment for executing generated functional and safety tests and evaluating test results against expected behaviors or hazardous conditions. It includes a test harness as well as an environment simulation of external events and conditions.

Chen, Ken↗
NASA NTRS2010

Phase Two Feasibility Study for Software Safety Requirements Analysis Using Model Checking

A feasibility study was performed on a representative aerospace system to determine the following: (1) the benefits and limitations to using SCADE , a commercially available tool for model checking, in comparison to using a proprietary tool that was studied previously [1] and (2) metrics for performing the model checking and for assessing the findings. This study was performed independently of the development task by a group unfamiliar with the system, providing a fresh, external perspective free from development bias.

Turgeon, Gregory↗
NASA NTRS2001

Putting Safety in the Software

Software is a vital component of nearly every piece of modern technology. It is not a 'sub-system', able to be separated out from the system as a whole, but a 'co-system' that controls, manipulates, or interacts with the hardware and with the end user. Software has its fingers into all the pieces of the pie. If that 'pie', the system, can lead to injury, death, loss of major equipment, or impact your business bottom line, then software safety becomes vitally important. Learning to think about software from a safety perspective is the focus of this paper. We want you to think of software as part of the safety critical system, a major part. This requires 'system thinking' - being able to grasp the whole picture. Software's contribution to modern technology is both good and potentially bad. Software allows more complex and useful devices to be built. It can also contribute to plane crashes and power outages. We want you to see software in a whole new light, see it as a contributor to system hazards, and also as a possible fix or mitigation to some of those hazards.

Wetherholt, Martha S.↗
DOE OSTI2020

Overview of the MCNP6® SQA Plan and Requirements [Memorandum]

For all X Computational Physics Division (XCP) software under the Associate Laboratory Directorate for Weapons Physics (ALDX), the Weapons Research Services Secure Networks and Assurance Group (WRS-SNA) manages the software quality assurance (SQA) plan, requirements and guidance with respect to development processes and tools to meet the broader LANL SQA requirements. Each XCP software product is categorized into one of three software types: Safety Software, Non-Safety Risk Significant Software, and Non-Safety Commercially Controlled Software. In 2018, using LANL Form 2033, the MCNP6 code was categorized by the XCP division as Non-Safety Commercially Controlled Software, provided in Appendix A. Using WRSFORM- 0001U, the MCNP6 code was graded as a Medium Impact software product, provided in Appendix B. Given these determinations, the WRS-AD-0010U SQA plan is followed for all MCNP6 developments, documentation and code releases.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2015

Planning the Unplanned Experiment: Towards Assessing the Efficacy of Standards for Safety-Critical Software

Safe use of software in safety-critical applications requires well-founded means of determining whether software is fit for such use. While software in industries such as aviation has a good safety record, little is known about whether standards for software in safety-critical applications 'work' (or even what that means). It is often (implicitly) argued that software is fit for safety-critical use because it conforms to an appropriate standard. Without knowing whether a standard works, such reliance is an experiment; without carefully collecting assessment data, that experiment is unplanned. To help plan the experiment, we organized a workshop to develop practical ideas for assessing software safety standards. In this paper, we relate and elaborate on the workshop discussion, which revealed subtle but important study design considerations and practical barriers to collecting appropriate historical data and recruiting appropriate experimental subjects. We discuss assessing standards as written and as applied, several candidate definitions for what it means for a standard to 'work,' and key assessment strategies and study techniques and the pros and cons of each. Finally, we conclude with thoughts about the kinds of research that will be required and how academia, industry, and regulators might collaborate to overcome the noted barriers.

Graydon, Patrick J.↗
NASA NTRS2009

Towards A Comprehensive Consideration of Epistemic Questions in Software System Safety

For any software system upon which lives depend, the most important question one can ask about it is, 'How do we know the system is safe?' Despite the critical importance of this question, no widely accepted, generally applicable answer exists. Instead, debate continues to rage over the question, with theorists and practitioners quarrelling with each other and amongst themselves. This paper suggests a possible way forward towards quelling the quarrels, based on refining the critical safety question into additional questions, which may be more likely to have answers on which a consensus can be reached.

Holloway, C. M.↗
NASA NTRS1996

Software Reliability Issues Concerning Large and Safety Critical Software Systems

This research was undertaken to provide NASA with a survey of state-of-the-art techniques using in industrial and academia to provide safe, reliable, and maintainable software to drive large systems. Such systems must match the complexity and strict safety requirements of NASA's shuttle system. In particular, the Launch Processing System (LPS) is being considered for replacement. The LPS is responsible for monitoring and commanding the shuttle during test, repair, and launch phases. NASA built this system in the 1970's using mostly hardware techniques to provide for increased reliability, but it did so often using custom-built equipment, which has not been able to keep up with current technologies. This report surveys the major techniques used in industry and academia to ensure reliability in large and critical computer systems.

Kamel, Khaled↗
DOE OSTI2017

Application of a bayesian belief network model to reliability assessment of nuclear safety-related software - 207

As the instrumentation and control (I and C) systems in nuclear power plants (NPPs) have been replaced with digital-based systems, the need to incorporate software failures into NPP probabilistic risk assessments has arisen. In order to assess the probability of software failure on demand, a Bayesian belief network (BBN) model was developed which estimates the number of defects and the resulting probability of software failure on demand in nuclear safety-related software. To assess the feasibility of the BBN framework, the BBN model was applied to the prototype Integrated Digital Protection System-Reactor Protection System (IDiPS-RPS) to estimate the number of remaining faults and the software failure probability of a target software. The developmental- and V and V-activities carried out during the IDiPS-RPS development process were evaluated based on the well-defined checklist derived by the V and V team and were estimated based on expert elicitation. In addition, the attribute evaluations and the number of FPs of the target software is provided as the inputs for the BBN model. The application results showed the feasibility of using BBNs for quantifying software failure probabilities and several insights were gained from the applications of the BBN model. The proposed BBN framework can be applied to estimate the software failure probability for other safety-related NPP software and provide an insight on modeling the software development process that involves iterations between different development phases. (authors)

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS2015

Planning the Unplanned Experiment: Assessing the Efficacy of Standards for Safety Critical Software

We need well-founded means of determining whether software is t for use in safety-critical applications. While software in industries such as aviation has an excellent safety record, the fact that software aws have contributed to deaths illustrates the need for justi ably high con dence in software. It is often argued that software is t for safety-critical use because it conforms to a standard for software in safety-critical systems. But little is known about whether such standards `work.' Reliance upon a standard without knowing whether it works is an experiment; without collecting data to assess the standard, this experiment is unplanned. This paper reports on a workshop intended to explore how standards could practicably be assessed. Planning the Unplanned Experiment: Assessing the Ecacy of Standards for Safety Critical Software (AESSCS) was held on 13 May 2014 in conjunction with the European Dependable Computing Conference (EDCC). We summarize and elaborate on the workshop's discussion of the topic, including both the presented positions and the dialogue that ensued.

Graydon, Patrick J.↗
NASA NTRS2002

Formalized pilot study of safety-critical software anomalies: final report

This report describes both the research techniques and the application results from the analysis of safety-critical software anomalies recorded post-launch on seven spacecraft: Galileo, Mars Global Surveyor, Cassini/Huygens, Deep Space 1, Mars Climate Orbiter, Mars Polar Lander, and Stardust.

software anomalies pilot study software safety↗
NASA NTRS1991

Safety

Software requirements, design, implementation, verification and validation, and especially management are affected by the need to produce safe software. This paper discusses the changes in the software life cycle that are necessary to ensure that software will execute without resulting in unacceptable risk. Software is being used increasingly to monitor and control safety-critical processes in which a run-time failure or error could result in unacceptable losses such as death, injury, loss of property, or environmental harm. Examples of such processes maybe found in transportation, energy, aerospace, basic industry, medicine, and defense systems.

Leveson, Nancy G.↗