Search NASA⌕ Search

SEARCH · Search NASA

Results for “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 19 records

TRISO Fuel’s Safety Functions, Contributions to Reactor Safety, and Necessary Safety Limits

Safety functions are the actions, passive or active, that structures, systems, and components of nuclear facility that contribute to the safety of the workers, the public, or the environment. Well-defined safety functions are the foundation of a solid safety case for a reactor. For reactors that use TRISO-coated particles, the TRISO fuel plays an important part of the safety case because of its ability to contain radionuclides in the fuel itself. This ability enables the use of a functional containment strategy for the reactor where radionuclide retention is the primary safety function supported by the safety functions of controlling reactivity control and controlling heat rejection. This paper establishes at a deeper level the role that TRISO fuel plays in each of these safety functions and associated quality assurance and testing requirements for TRISO particle manufacturing to ensure these safety functions. Safety limits necessary to protect these safety functions include: operational limits, time at temperature limits, and fission gas release activity limits. In conclusion, this approach demonstrates the role that specific aspects of TRISO fuel play in protecting the safety of workers, the public, and the environment.

11 - NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

Manned space flight nuclear system safety. Volume 5: Nuclear System safety guidelines. Part 1: Space base nuclear safety

The design and operations guidelines and requirements developed in the study of space base nuclear system safety are presented. Guidelines and requirements are presented for the space base subsystems, nuclear hardware (reactor, isotope sources, dynamic generator equipment), experiments, interfacing vehicles, ground support systems, range safety and facilities. Cross indices and references are provided which relate guidelines to each other, and to substantiating data in other volumes. The guidelines are intended for the implementation of nuclear safety related design and operational considerations in future space programs.

Source record↗

Manned space flight nuclear system safety. Volume 3: Reactor system preliminary nuclear safety analysis. Part 3: Nuclear Safety Analysis Document (NSAD)

Nuclear safety analysis as applied to a space base mission is presented. The nuclear safety analysis document summarizes the mission and the credible accidents/events which may lead to nuclear hazards to the general public. The radiological effects and associated consequences of the hazards are discussed in detail. The probability of occurrence is combined with the potential number of individuals exposed to or above guideline values to provide a measure of accident and total mission risk. The overall mission risk has been determined to be low with the potential exposure to or above 25 rem limited to less than 4 individuals per every 1000 missions performed. No radiological risk to the general public occurs during the prelaunch phase at KSC. The most significant risks occur from prolonged exposure to reactor debris following land impact generally associated with the disposal phase of the mission where fission product inventories can be high.

Source record↗

NASA System Safety Handbook: System Safety Framework and Concepts for Implementation - Volume 1

System safety assessment is defined in NPR 8715.3C, NASA General Safety Program Requirements as a disciplined, systematic approach to the analysis of risks resulting from hazards that can affect humans, the environment, and mission assets. Achievement of the highest practicable degree of system safety is one of NASA's highest priorities. Traditionally, system safety assessment at NASA and elsewhere has focused on the application of a set of safety analysis tools to identify safety risks and formulate effective controls.1 Familiar tools used for this purpose include various forms of hazard analyses, failure modes and effects analyses, and probabilistic safety assessment (commonly also referred to as probabilistic risk assessment (PRA)). In the past, it has been assumed that to show that a system is safe, it is sufficient to provide assurance that the process for identifying the hazards has been as comprehensive as possible and that each identified hazard has one or more associated controls. The NASA Aerospace Safety Advisory Panel (ASAP) has made several statements in its annual reports supporting a more holistic approach. In 2006, it recommended that "... a comprehensive risk assessment, communication and acceptance process be implemented to ensure that overall launch risk is considered in an integrated and consistent manner." In 2009, it advocated for "... a process for using a risk-informed design approach to produce a design that is optimally and sufficiently safe." As a rationale for the latter advocacy, it stated that "... the ASAP applauds switching to a performance-based approach because it emphasizes early risk identification to guide designs, thus enabling creative design approaches that might be more efficient, safer, or both." For purposes of this preface, it is worth mentioning three areas where the handbook emphasizes a more holistic type of thinking. First, the handbook takes the position that it is important to not just focus on risk on an individual basis but to consider measures of aggregate safety risk and to ensure wherever possible that there be quantitative measures for evaluating how effective the controls are in reducing these aggregate risks. The term aggregate risk, when used in this handbook, refers to the accumulation of risks from individual scenarios that lead to a shortfall in safety performance at a high level: e.g., an excessively high probability of loss of crew, loss of mission, planetary contamination, etc. Without aggregated quantitative measures such as these, it is not reasonable to expect that safety has been optimized with respect to other technical and programmatic objectives. At the same time, it is fully recognized that not all sources of risk are amenable to precise quantitative analysis and that the use of qualitative approaches and bounding estimates may be appropriate for those risk sources. Second, the handbook stresses the necessity of developing confidence that the controls derived for the purpose of achieving system safety not only handle risks that have been identified and properly characterized but also provide a general, more holistic means for protecting against unidentified or uncharacterized risks. For example, while it is not possible to be assured that all credible causes of risk have been identified, there are defenses that can provide protection against broad categories of risks and thereby increase the chances that individual causes are contained. Third, the handbook strives at all times to treat uncertainties as an integral aspect of risk and as a part of making decisions. The term "uncertainty" here does not refer to an actuarial type of data analysis, but rather to a characterization of our state of knowledge regarding results from logical and physical models that approximate reality. Uncertainty analysis finds how the output parameters of the models are related to plausible variations in the input parameters and in the modeling assumptions. The evaluation of unrtainties represents a method of probabilistic thinking wherein the analyst and decision makers recognize possible outcomes other than the outcome perceived to be "most likely." Without this type of analysis, it is not possible to determine the worth of an analysis product as a basis for making decisions related to safety and mission success. In line with these considerations the handbook does not take a hazard-analysis-centric approach to system safety. Hazard analysis remains a useful tool to facilitate brainstorming but does not substitute for a more holistic approach geared to a comprehensive identification and understanding of individual risk issues and their contributions to aggregate safety risks. The handbook strives to emphasize the importance of identifying the most critical scenarios that contribute to the risk of not meeting the agreed-upon safety objectives and requirements using all appropriate tools (including but not limited to hazard analysis). Thereafter, emphasis shifts to identifying the risk drivers that cause these scenarios to be critical and ensuring that there are controls directed toward preventing or mitigating the risk drivers. To address these and other areas, the handbook advocates a proactive, analytic-deliberative, risk-informed approach to system safety, enabling the integration of system safety activities with systems engineering and risk management processes. It emphasizes how one can systematically provide the necessary evidence to substantiate the claim that a system is safe to within an acceptable risk tolerance, and that safety has been achieved in a cost-effective manner. The methodology discussed in this handbook is part of a systems engineering process and is intended to be integral to the system safety practices being conducted by the NASA safety and mission assurance and systems engineering organizations. The handbook posits that to conclude that a system is adequately safe, it is necessary to consider a set of safety claims that derive from the safety objectives of the organization. The safety claims are developed from a hierarchy of safety objectives and are therefore hierarchical themselves. Assurance that all the claims are true within acceptable risk tolerance limits implies that all of the safety objectives have been satisfied, and therefore that the system is safe. The acceptable risk tolerance limits are provided by the authority who must make the decision whether or not to proceed to the next step in the life cycle. These tolerances are therefore referred to as the decision maker's risk tolerances. In general, the safety claims address two fundamental facets of safety: 1) whether required safety thresholds or goals have been achieved, and 2) whether the safety risk is as low as possible within reasonable impacts on cost, schedule, and performance. The latter facet includes consideration of controls that are collective in nature (i.e., apply generically to broad categories of risks) and thereby provide protection against unidentified or uncharacterized risks.

Dezfuli, Homayoon↗

Manned space flight nuclear system safety. Voluem 5: Nuclear system safety guidelines. Part 2: Space shuttle/nuclear payloads safety

The design and operations guidelines and requirements developed in the study of space shuttle nuclear system transportation are presented. Guidelines and requirements are presented for the shuttle, nuclear payloads (reactor, isotope-Brayton and small isotope sources), ground support systems and facilities. Cross indices and references are provided which relate guidelines to each other, and to substantiating data in other volumes. The guidelines are intended for the implementation of nuclear safety related design and operational considerations in future space programs.

Source record↗

Safety moments in chemical safety education.

Chemical safety education is a critical aspect of an integrated culture of safety in academic research settings. Showcasing best practices and sharing practical solutions for recognizing hazards and minimizing risks represent one way of reinforcing a research community's actions, attitudes, and behavior toward safety. For goals of improving chemical safety education with nonformal endeavors, safety moments are similar to 1-2 slides that focus on raising awareness and knowledge for routine safety issues in research laboratories. Intended to catalyze brief discussions at the beginning of meetings and presentations, these materials provide a proactive way for students and faculty to engage in open communication on diverse research safety topics across science and engineering. This commentary provides an overview of designing effective safety moments and tailoring them to highlight practical safety needs and considerations. Key components of model safety moment slides are presented, alongside centralized resources assembled by student-led laboratory safety teams, which can also be extended to posters, social media platforms, online videos, and other forms of scientific communication. Combined with both top-down backing from institution leaders and bottom-up support from student researchers, safety moments remain a low-barrier risk reduction strategy that is easy to implement, encourages local dialogue on safety, combats complacency, and holds potential for facilitating long-term improvements to academic lab safety culture.

Communication/Writing↗

Product Engineering Class in the Software Safety Risk Taxonomy for Building Safety-Critical Systems

When software safety requirements are imposed on legacy safety-critical systems, retrospective safety cases need to be formulated as part of recertifying the systems for further use and risks must be documented and managed to give confidence for reusing the systems. The SEJ Software Development Risk Taxonomy [4] focuses on general software development issues. It does not, however, cover all the safety risks. The Software Safety Risk Taxonomy [8] was developed which provides a construct for eliciting and categorizing software safety risks in a straightforward manner. In this paper, we present extended work on the taxonomy for safety that incorporates the additional issues inherent in the development and maintenance of safety-critical systems with software. An instrument called a Software Safety Risk Taxonomy Based Questionnaire (TBQ) is generated containing questions addressing each safety attribute in the Software Safety Risk Taxonomy. Software safety risks are surfaced using the new TBQ and then analyzed. In this paper we give the definitions for the specialized Product Engineering Class within the Software Safety Risk Taxonomy. At the end of the paper, we present the tool known as the 'Legacy Systems Risk Database Tool' that is used to collect and analyze the data required to show traceability to a particular safety standard

Hill, Janice↗

Workshop on the Role of Design Assurance in System-Wide Safety’s Safety Demonstrator Series

This report summarizes a three-hour hybrid in-person/online workshop on June 7, 2024 on the topic of design assurance and the Safety Demonstrator Series (SDS), which was held at NASA Ames Research Center. The SDS provides an operational demonstration of, and recommendations for, requirements and standards necessary to monitor, assess, and mitigate risks to assure safety in disaster-oriented operations. Over sixty NASA personnel participated in the workshop. Four main topics were discussed: (1) assurance needs for the Safety Demonstrator Series, (2) assurance and the In-Time Aviation Safety Management System (IASMS), (3) in-time assurance: existing efforts and future opportunities, and (4) demonstrating assurance tools in the Safety Demonstrators. Key takeaways are as follows: 1. Design assurance tools can be used to assure an In-Time Aviation Safety Management System, the systems that comprise it, and other systems or missions. Assurance must consider both systems and components and include the interactions between elements in both a systems/aircraft context and a systems-of-systems/airspace context. 2. Design-time assurance activities can support the identification of monitors needed for operational assurance activities (i.e., the “monitor” function in the monitor-assess-mitigate paradigm at the heart of the IASMS concept). 3. A major opportunity for design-time assurance tools to contribute to the IASMS concept is to support rapid re-validation of systems. This will be particularly important for (1) supporting novel operations in the IASMS, where operational data may disprove design-time assumptions (motivating re-analysis of system safety) and (2) adapting technologies (e.g., AI/ML for autonomous operations) to new operational domains, where there may be new or different safety considerations not included in the initial scope of operations. 4. There are several design assurance tools under development in the System-Wide Safety project that can support assurance of Services, Functions, and Capabilities (SFCs) in the Safety Demonstrators. Transitioning these tools from one-off research projects into a functioning part of IASMS assurance will require closer integration between these tools. 5. It is not clear whether the role of design assurance tools is primarily as a part of IASMS architecture or as an external check on IASMS. The workshop consisted of four discussion topics initiated via four lightning talks by System-Wide Safety researchers. Discussions utilized Mural to engage both in-person and online participants in the hybrid format. Polls and surveys were also utilized to gather participant input. The workshop closed with a reflection activity for participants, as well as new ideas for collaboration and coordination of ongoing System-Wide Safety research.

design assurance↗

Another Approach to Enhance Airline Safety: Using Management Safety Tools

The ultimate goal of conducting an accident investigation is to prevent similar accidents from happening again and to make operations safer system-wide. Based on the findings extracted from the investigation, the "lesson learned" becomes a genuine part of the safety database making risk management available to safety analysts. The airline industry is no exception. In the US, the FAA has advocated the usage of the System Safety concept in enhancing safety since 2000. Yet, in today s usage of System Safety, the airline industry mainly focuses on risk management, which is a reactive process of the System Safety discipline. In order to extend the merit of System Safety and to prevent accidents beforehand, a specific System Safety tool needs to be applied; so a model of hazard prediction can be formed. To do so, the authors initiated this study by reviewing 189 final accident reports from the National Transportation Safety Board (NTSB) covering FAR Part 121 scheduled operations. The discovered accident causes (direct hazards) were categorized into 10 groups Flight Operations, Ground Crew, Turbulence, Maintenance, Foreign Object Damage (FOD), Flight Attendant, Air Traffic Control, Manufacturer, Passenger, and Federal Aviation Administration. These direct hazards were associated with 36 root factors prepared for an error-elimination model using Fault Tree Analysis (FTA), a leading tool for System Safety experts. An FTA block-diagram model was created, followed by a probability simulation of accidents. Five case studies and reports were provided in order to fully demonstrate the usefulness of System Safety tools in promoting airline safety.

Lu, Chien-tsug↗

Identifying Emerging Safety Threats Through Topic Modeling in the Aviation Safety Reporting System: A Covid-19 Study

The NASA Aviation Safety Reporting System (ASRS) is a voluntary, confidential aviation safety reporting system. The ASRS receives reports from pilots, air traffic controllers, flight attendants, and others involved in aviation operations. The reports are de-identified and coded by ASRS expert safety analysts, and a short descriptive synopsis is written to describe the safety issue. The de-identified reports are then disseminated to the aviation community in many ways, including via an online database, Safety Alert Bulletins, For Your Information Notices, and the CALLBACK newsletter. In this work, we consider whether we can improve the grouping, linking, and understanding of safety concerns through topic modeling. Specifically, we use topic modeling as a building block to identify emerging safety threats over time. This unsupervised approach, we argue, offers the flexibility to identify new emerging themes in this large dataset by constructing different timelines based on the content similarity of ASRS report narratives. This method's unsupervised nature improves upon related research, which is limited to pre-defined labels and therefore can not fully capture emerging safety threats. We apply our method to all ASRS reports in 2020 to assess if the generated timelines can highlight COVID-19 as it is emerging as a safety threat in incoming ASRS reports. We perform both a quantitative and qualitative evaluation of the automatically constructed timelines. The qualitative evaluation is performed by describing the evolution of top terms in the timelines, generated by our method, which we found explicitly convey the themes of COVID-19. Separately, we use a set of 1,213 COVID-19 reports from 2020 that were manually identified by ASRS analysts to quantitatively evaluate the COVID-19 reports distribution across the timelines. Our results have shown that COVID-19 emergence can be identified using the top terms that were generated by topic modeling. The top terms in topic modeling therefore can serve as a summary alternative to manually inspecting reports. Moreover, leveraging the manually identified COVID-19 reports, we found the manually identified timelines accounted for over 70% of the COVID-19 reports curated by the ASRS analysts, which demonstrates the potential of this approach for facilitating the understanding of safety concerns as they emerge and evolve. This method shows great potential to understand aerospace safety threats and other narrative- driven incident report databases.

ASRS↗

Identifying Emerging Safety Threats Through Topic Modeling in the Aviation Safety Reporting System: A COVID-19 Study

The NASA Aviation Safety Reporting System (ASRS) is a voluntary, confidential aviation safety reporting system. The ASRS receives reports from pilots, air traffic controllers, flight attendants, and others involved in aviation operations. The reports are de-identified and coded by ASRS expert safety analysts, and a short descriptive synopsis is written to describe the safety issue. The de-identified reports are then disseminated to the aviation community in many ways, including via an online database, Safety Alert Bulletins, For Your Information Notices, and the CALLBACK newsletter. In this work, we consider whether we can improve the grouping, linking, and understanding of safety concerns through topic modeling. Specifically, we use topic modeling as a building block to identify emerging safety threats over time. This unsupervised approach, we argue, offers the flexibility to identify new emerging themes in this large dataset by constructing different timelines based on the content similarity of ASRS report narratives. This method's unsupervised nature improves upon related research, which is limited to pre-defined labels and therefore can not fully capture emerging safety threats. We apply our method to all ASRS reports in 2020 to assess if the generated timelines can highlight COVID-19 as it is emerging as a safety threat in incoming ASRS reports. We perform both a quantitative and qualitative evaluation of the automatically constructed timelines. The qualitative evaluation is performed by describing the evolution of top terms in the timelines, generated by our method, which we found explicitly convey the themes of COVID-19. Separately, we use a set of 1,213 COVID-19 reports from 2020 that were manually identified by ASRS analysts to quantitatively evaluate the COVID-19 reports distribution across the timelines. Our results have shown that COVID-19 emergence can be identified using the top terms that were generated by topic modeling. The top terms in topic modeling therefore can serve as a summary alternative to manually inspecting reports. Moreover, leveraging the manually identified COVID-19 reports, we found the manually identified timelines accounted for over 70% of the COVID-19 reports curated by the ASRS analysts, which demonstrates the potential of this approach for facilitating the understanding of safety concerns as they emerge and evolve. This method shows great potential to understand aerospace safety threats and other narrative- driven incident report databases.

ASRS↗

HAZARD ANALYSIS OF DIGITAL ENGINEERED SAFETY FEATURES ACTUATION SYSTEM IN ADVANCED NUCLEAR POWER PLANTS USING A REDUNDANCY-GUIDED APPROACH

Replacing the existing aging analog instrumentation and control (I&C) systems with modern safety control and protection digital technology offers one of the foremost means of performance improvements and cost reductions for the existing nuclear power plants (NPPs). However, the qualification of digital I&C systems remains a challenge, especially considering the issue of software common-cause failures (CCFs), which are difficult to address. With the application and upgrades of advanced digital I&C systems, software CCFs have become a potential threat to plant safety because most redundant designs use similar digital platforms or software in the operating and application systems. With complex designs of multilayer redundancy to meet the single-failure criterion, digital I&C safety systems (e.g., engineered safety-features actuation system [ESFAS]) are of a particular concern in the U.S. Nuclear Regulatory Commission (NRC) licensing procedures. This paper applies a modularized approach to conduct redundancy-guided systems-theoretic hazard analysis for an advanced digital ESFAS with multilevel redundancy designs. Systematic methods and risk-informed tools are incorporated to address both hardware and software CCFs, which provide guidance to eliminate the triggers of potential single points of failure in the design of digital safety systems in advanced plant designs.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

Criticality Safety Evaluation Project Development for University of California Berkely Nuclear Criticality Safety Pipeline Course

The Nuclear Criticality Safety Division at Lawrence Livermore National Laboratory (LLNL) has taken a unique approach to developing criticality safety evaluation topics in support of the University of California Berkeley criticality safety pipeline course. The evaluation topics are designed to go beyond the typical evaluation examples used for many training courses including vault storage and variations on storage arrays. These types of evaluations provide in-depth analysis into the fundamentals of criticality safety and are complex but may be far off from what a new criticality safety engineer may actually be evaluating. To provide more practical examples of criticality safety evaluation topics that are better fit for the knowledge level of a criticality safety engineer in-training, variations of current and future operations and research operations performed at LLNL are used as evaluation topics. Additionally, an emphasis on research is included in all evaluation topics as it allows students to take advantage of the concepts learned in class to apply them for process improvement, engineering equipment that is favorable for criticality safety, and negotiation tactics to work with operations personnel. The process used by LLNL to develop project topics for the pipeline course is provided in this paper. The intent is to provide an alternative technique for training students and potentially younger staff members in criticality safety on developing criticality safety evaluations.

42 ENGINEERING↗

NASA System Safety Handbook. Volume 2: System Safety Concepts, Guidelines, and Implementation Examples

This is the second of two volumes that collectively comprise the NASA System Safety Handbook. Volume 1 (NASASP-210-580) was prepared for the purpose of presenting the overall framework for System Safety and for providing the general concepts needed to implement the framework. Volume 2 provides guidance for implementing these concepts as an integral part of systems engineering and risk management. This guidance addresses the following functional areas: 1.The development of objectives that collectively define adequate safety for a system, and the safety requirements derived from these objectives that are levied on the system. 2.The conduct of system safety activities, performed to meet the safety requirements, with specific emphasis on the conduct of integrated safety analysis (ISA) as a fundamental means by which systems engineering and risk management decisions are risk-informed. 3.The development of a risk-informed safety case (RISC) at major milestone reviews to argue that the systems safety objectives are satisfied (and therefore that the system is adequately safe). 4.The evaluation of the RISC (including supporting evidence) using a defined set of evaluation criteria, to assess the veracity of the claims made therein in order to support risk acceptance decisions.

Safety Case↗

Deriving Safety Cases for the Formal Safety Certification of Automatically Generated Code

We present an approach to systematically derive safety cases for automatically generated code from information collected during a formal, Hoare-style safety certification of the code. This safety case makes explicit the formal and informal reasoning principles, and reveals the top-level assumptions and external dependencies that must be taken into account; however, the evidence still comes from the formal safety proofs. It uses a generic goal-based argument that is instantiated with respect to the certified safety property (i.e., safety claims) and the program. This will be combined with a complementary safety case that argues the safety of the framework itself, in particular the correctness of the Hoare rules with respect to the safety property and the trustworthiness of the certification system and its individual components. Keywords: Automated code generation, Hoare logic, formal code certification, safety case, Goal Structuring Notation.

Basir, Nurlida↗

Software Safety Risk in Legacy Safety-Critical Computer Systems

Safety-critical computer systems must be engineered to meet system and software safety requirements. For legacy safety-critical computer systems, software safety requirements may not have been formally specified during development. When process-oriented software safety requirements are levied on a legacy system after the fact, where software development artifacts don't exist or are incomplete, the question becomes 'how can this be done?' The risks associated with only meeting certain software safety requirements in a legacy safety-critical computer system must be addressed should such systems be selected as candidates for reuse. This paper proposes a method for ascertaining formally, a software safety risk assessment, that provides measurements for software safety for legacy systems which may or may not have a suite of software engineering documentation that is now normally required. It relies upon the NASA Software Safety Standard, risk assessment methods based upon the Taxonomy-Based Questionnaire, and the application of reverse engineering CASE tools to produce original design documents for legacy systems.

Hill, Janice↗

Software Safety Risk in Legacy Safety-Critical Computer Systems

Safety Standards contain technical and process-oriented safety requirements. Technical requirements are those such as "must work" and "must not work" functions in the system. Process-Oriented requirements are software engineering and safety management process requirements. Address the system perspective and some cover just software in the system > NASA-STD-8719.13B Software Safety Standard is the current standard of interest. NASA programs/projects will have their own set of safety requirements derived from the standard. Safety Cases: a) Documented demonstration that a system complies with the specified safety requirements. b) Evidence is gathered on the integrity of the system and put forward as an argued case. [Gardener (ed.)] c) Problems occur when trying to meet safety standards, and thus make retrospective safety cases, in legacy safety-critical computer systems.

Hill, Janice L.↗

Traceability of Software Safety Requirements in Legacy Safety Critical Systems

How can traceability of software safety requirements be created for legacy safety critical systems? Requirements in safety standards are imposed most times during contract negotiations. On the other hand, there are instances where safety standards are levied on legacy safety critical systems, some of which may be considered for reuse for new applications. Safety standards often specify that software development documentation include process-oriented and technical safety requirements, and also require that system and software safety analyses are performed supporting technical safety requirements implementation. So what can be done if the requisite documents for establishing and maintaining safety requirements traceability are not available?

Hill, Janice L.↗