Search NASA⌕ Search

SEARCH · Search NASA

Results for “risk identification”

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 37 records · Page 2

Identification of Risks to Eva Created By Ambient Lighting Conditions at the Lunar South Pole

In the coming years, NASA’s Artemis Campaign intends to return humans to the Moon, both to explore and to establish a permanent human presence. The targeted landing and habitation sites are near the Lunar South Pole (LSP). Compared to the middle latitudes where the Apollo landings occurred, the sun at the LSP is consistently low in the sky, creating a much more challenging visual experience. The NASA Engineering & Safety Center (NESC) is working to characterize the extremes in ambient illumination that astronauts will encounter at the LSP, and to help programs characterize the lighting systems and glare protection that will be required to conduct safe surface operations. This paper will describe the LSP natural environments, and efforts to simulate that visual experience. It will also explain the risks derived from the lighting environment for the mission goals currently planned, and the kinds of new capabilities both in simulation techniques and in surface equipment that will be required to support those mission goals.

Identification of Risks↗

Machine Learning in Infectious Disease for Risk Factor Identification and Hypothesis Generation: Proof of Concept Using Invasive Candidiasis

Machine learning (ML) models can handle large data sets without assuming underlying relationships and can be useful for evaluating disease characteristics, yet they are more commonly used for predicting individual disease risk than for identifying factors at the population level. We offer a proof of concept applying random forest (RF) algorithms to Candida-positive hospital encounters in an electronic health record database of patients in the United States. Candida-positive encounters were extracted from the Cerner HealthFacts database; invasive infections were laboratory-positive sterile site Candida infections. Features included demographics, admission source, care setting, physician specialty, diagnostic and procedure codes, and medications received before the first positive Candida culture. We used RF to assess risk factors for 3 outcomes: any invasive candidiasis (IC) vs non-IC, within-species IC vs non-IC (eg, invasive C. glabrata vs noninvasive C. glabrata), and between-species IC (eg, invasive C. glabrata vs all other IC). Fourteen of 169 (8%) variables were consistently identified as important features in the ML models. When evaluating within-species IC, for example, invasive C. glabrata vs non-invasive C. glabrata, we identified known features like central venous catheters, intensive care unit stay, and gastrointestinal operations. In contrast, important variables for invasive C. glabrata vs all other IC included renal disease and medications like diabetes therapeutics, cholesterol medications, and antiarrhythmics. Known and novel risk factors for IC were identified using ML, demonstrating the hypothesis-generating utility of this approach for infectious disease conditions about which less is known, specifically at the species level or for rarer diseases.

60 APPLIED LIFE SCIENCES↗

A Risk Analysis Tool for Estimating the Risk of Electrical Failures Due to Human Induced Defects

Aerospace electrical systems are required to withstand and adequately operate in extremely harsh environments that include, for example, high radiation exposure, temperature extremes, intense vibrational stress and drastic temperature cycling. The nature of aerospace electronics also demands high reliability since, with very few exceptions, there is no chance for hardware servicing or repairs. Common risk mitigation techniques for this type of situation are to perform a Reliability Analysis of the system throughout the development cycle, and to use electrical components that are regarded as “high reliability” because of additional controls and requirements applied in their design, manufacturing and testing. Unfortunately, studies have shown that even though these techniques are used, many systems fail to meet mission requirements well before the predicted lifetimes. This paper presents the analysis of failures of electrical parts, experienced during various stages of system development, at NASA Goddard Space Flight Center, Greenbelt MD, between the years 2001 and 2013. These components were subjected to qualification, screening and testing in which the goal was to ensure that the components would survive the stresses of the mission. The analysis categorizes failures by part type and failure mechanisms. One of the results of the analysis was the realization that a surprising proportion of failures experienced during system integration and testing were caused by human error (i.e. human induced defect). Further analysis included the determination of root failure mechanisms and any influencing factors contributing to these failures. The major causes of these defects were attributed to electrostatic damage (ESD), electrical overstress (EOS), mechanical overstress (MOS), and thermal overstress (TOS). Finally, the study proposes a risk analysis tool which incorporates these major causes for the failures, termed error-producing conditions (EPCs), and a proportionality factor representing the number of each type of failure that has occurred at the facility under study. These factors are quantified and used to communicate the risk of human induced defects for the assembly, integration and testing of space hardware based on the system’s electrical parts list. The new risk identification can trigger risk-mitigating actions more effectively, based on the presence of component categories or other hazardous conditions that have a history of failure due to human error.

Majewicz, Peter J.↗

Risk Management for Human Support Technology Development

NASA requires continuous risk management for all programs and projects. The risk management process identifies risks, analyzes their impact, prioritizes them, develops and carries out plans to mitigate or accept them, tracks risks and mitigation plans, and communicates and documents risk information. Project risk management is driven by the project goal and is performed by the entire team. Risk management begins early in the formulation phase with initial risk identification and development of a risk management plan and continues throughout the project life cycle. This paper describes the risk management approach that is suggested for use in NASA's Human Support Technology Development. The first step in risk management is to identify the detailed technical and programmatic risks specific to a project. Each individual risk should be described in detail. The identified risks are summarized in a complete risk list. Risk analysis provides estimates of the likelihood and the qualitative impact of a risk. The likelihood and impact of the risk are used to define its priority location in the risk matrix. The approaches for responding to risk are either to mitigate it by eliminating or reducing the effect or likelihood of a risk, to accept it with a documented rationale and contingency plan, or to research or monitor the risk, The Human Support Technology Development program includes many projects with independently achievable goals. Each project must do independent risk management, considering all its risks together and trading them against performance, budget, and schedule. Since the program can succeed even if some projects fail, the program risk has a complex dependence on the individual project risks.

jones, Harry↗

Millimeter wave satellite concepts, volume 1

The identification of technologies necessary for development of millimeter spectrum communication satellites was examined from a system point of view. Development of methodology based on the technical requirements of potential services that might be assigned to millimeter wave bands for identifying the viable and appropriate technologies for future NASA millimeter research and development programs, and testing of this methodology with selected user applications and services were the goals of the program. The entire communications network, both ground and space subsystems was studied. Cost, weight, and performance models for the subsystems, conceptual design for point-to-point and broadcast communications satellites, and analytic relationships between subsystem parameters and an overall link performance are discussed along with baseline conceptual systems, sensitivity studies, model adjustment analyses, identification of critical technologies and their risks, and brief research and development program scenarios for the technologies judged to be moderate or extensive risks. Identification of technologies for millimeter satellite communication systems, and assessment of the relative risks of these technologies, was accomplished through subsystem modeling and link optimization for both point-to-point and broadcast applications.

Hilsen, N. B.↗

Rotor systems research aircraft predesign study. Volume 3: Predesign report

The features of two aircraft designs were selected to be included in the single RSRA configuration. A study was conducted for further preliminary design and a more detailed analysis of development plans and costs. An analysis was also made of foreseeable technical problems and risks, identification of parallel research which would reduce risks and/or add to the basic capability of the aircraft, and a draft aircraft specification.

Schmidt, S. A.↗

Overview and Status of the Bioastronautics Critical Path Roadmap (BCPR)

Viewgraphs on the status and overview of the Bioastronautics Critical Path Roadmap (BCPR) are presented. The topics include: 1) BCPR Objectives; 2) BCPR and OBPR Program Management; 3) BCPR Disciplines & Cross-Cutting Areas; 4) Characteristics of BCPR Reference Missions; 5) Bioastronautics Timetable (notional); 6) BCPR Processes Risk Identification, Assessment, and Management; 7) Types of BCPR Risks; 8) Enabling Questions Categories; 9) Risk Mitigation Status; 10) Defining Levels of Accepted Risk; 11) BCPR Integration; 12) BCPR Implementation, Integration, and Validation; 13) BCPR Refinement Schedule; 14) Academy Review; 15) Rating Bioastronautics Risks; 16) Risk Rating Exercises; 17) Human Health Risk Assessment Criteria (examples); 18) A Recent Risk Rating Exercise; 19) Consensus Workshop Background; 20) Consensus Workshop Rating Analysis; 21) Consensus Workshop Selected Preliminary Recommendations; and 22) Access to BCPR Content.

Charles, John↗

Incorporating Risk

This presentation is about cost risk identification and estimation which is only a part of risk management. The purpose of this step is to identify common software risks, to assess their impact on the cost estimate, and to make revisions to the estimate based on these impacts.

Risk identifcation↗

Root Source Analysis/ValuStream[Trade Mark] - A Methodology for Identifying and Managing Risks

Root Source Analysis (RoSA) is a systems engineering methodology that has been developed at NASA over the past five years. It is designed to reduce costs, schedule, and technical risks by systematically examining critical assumptions and the state of the knowledge needed to bring to fruition the products that satisfy mission-driven requirements, as defined for each element of the Work (or Product) Breakdown Structure (WBS or PBS). This methodology is sometimes referred to as the ValuStream method, as inherent in the process is the linking and prioritizing of uncertainties arising from knowledge shortfalls directly to the customer's mission driven requirements. RoSA and ValuStream are synonymous terms. RoSA is not simply an alternate or improved method for identifying risks. It represents a paradigm shift. The emphasis is placed on identifying very specific knowledge shortfalls and assumptions that are the root sources of the risk (the why), rather than on assessing the WBS product(s) themselves (the what). In so doing RoSA looks forward to anticipate, identify, and prioritize knowledge shortfalls and assumptions that are likely to create significant uncertainties/ risks (as compared to Root Cause Analysis, which is most often used to look back to discover what was not known, or was assumed, that caused the failure). Experience indicates that RoSA, with its primary focus on assumptions and the state of the underlying knowledge needed to define, design, build, verify, and operate the products, can identify critical risks that historically have been missed by the usual approaches (i.e., design review process and classical risk identification methods). Further, the methodology answers four critical questions for decision makers and risk managers: 1. What s been included? 2. What's been left out? 3. How has it been validated? 4. Has the real source of the uncertainty/ risk been identified, i.e., is the perceived problem the real problem? Users of the RoSA methodology have characterized it as a true bottoms up risk assessment.

Brown, Richard Lee↗

Deployment of an Advanced Electrocardiographic Analysis (A-ECG) to Detect Cardiovascular Risk in Career Firefighters

INTRODUCTION Sudden cardiac death is the leading cause of line of duty death among firefighters, accounting for approximately 45% of fatalities annually. Firefighters perform strenuous muscular work while wearing heavy, encapsulating personal protective equipment in high ambient temperatures, under chaotic and emotionally stressful conditions. These factors can precipitate sudden cardiac events like myocardial infarction, serious dysrhythmias, or cerebrovascular accidents in firefighters with underlying cardiovascular disease. Screening for cardiovascular risk factors is recommended but not always followed in this population. PHASER is a project charged with identifying and prioritizing risk factors in emergency responders. We have deployed an advanced ECG (A-ECG) system developed at NASA for improved sensitivity and specificity in the detection of cardiac risk. METHODS Forty-four professional firefighters were recruited to perform comprehensive baseline assessments including tests of aerobic performance and laboratory tests for fasting lipid profiles and glucose. Heart rate and conventional 12-lead ECG were obtained at rest and during incremental treadmill exercise testing (XT). In addition, a 5-min resting 12-lead A-ECG was obtained in a subset of firefighters (n=18) and transmitted over a secure networked system to a physician collaborator at NASA for advanced-ECG analysis. This A-ECG system has been proven, using myocardial perfusion and other imaging, to accurately identify a number of cardiac pathologies including coronary artery disease (CAD), left ventricular hypertrophy, hypertrophic cardiomyopathy, non-ischemic cardiomyopathy, and ischemic cardiomyopathy. RESULTS Subjects mean (SD) age was 43 (8) years, weight 91 (13) kg, and BMI of 28 (3) kg/square meter. Maximum oxygen uptake (VO2max) was 39 (9) ml/kg/min. This compares with the 45th %ile in healthy reference values and a recommended standard of 42 ml/kg/min for firefighters. The metabolic threshold (VO2Theta) above which lactate accumulates was 23 (8) ml/kg/min. The chronotropic index, a measure of cardiovascular strain during XT was 35 (8) /L compared with reference values for men of 40 /L. Total cholesterol, LDL-C and HDL-C were 202 (34),126 (29), and 55 (15) mg/dl, respectively. Fifty-one percent of subjects had .3 cardiovascular risk factors, 2 subjects had resting hypertension (BP.140/90), and 23 had pre-hypertension (.120/80 but <140/90). Seven had exaggerated exercise induced hypertension but only one had ST depression on XT ECG, at least one positive A-ECG score for CAD, and documented CAD based on cardiology referral. While all other subjects, including those with fewer risk factors, higher aerobic fitness, and normal exercise ECGs, were classified as healthy by A-ECG, there was no trend for association between risk factors and any of 20 A-ECG parameters in the grouped data. CONCLUSIONS A-ECG screening correctly identified the individual with CAD although there was no trend for A-ECG parameters to distinguish those with elevated BP or multiple risk factors but normal XT ECG. We have demonstrated that a new technology, advanced-ECG, can be introduced for remote firefighter risk assessment. This simple, time and cost-effective approach to risk identification that can be acquired remotely and transmitted securely can detect individuals potentially at risk for line-of-duty death. Additional research is needed to further document its value.

Dolezal, B. A.↗

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↗

Engineering Lessons Learned and Systems Engineering Applications

Systems Engineering is fundamental to good engineering, which in turn depends on the integration and application of engineering lessons learned and technical standards. Thus, good Systems Engineering also depends on systems engineering lessons learned from within the aerospace industry being documented and applied. About ten percent of the engineering lessons learned documented in the NASA Lessons Learned Information System are directly related to Systems Engineering. A key issue associated with lessons learned datasets is the communication and incorporation of this information into engineering processes. Systems Engineering has been defined (EINIS-632) as "an interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and life-cycle balanced set of system people, product, and process solutions that satisfy customer needs". Designing reliable space-based systems has always been a goal for NASA, and many painful lessons have been learned along the way. One of the continuing functions of a system engineer is to compile development and operations "lessons learned" documents and ensure their integration into future systems development activities. They can produce insights and information for risk identification identification and characterization. on a new project. Lessons learned files from previous projects are especially valuable in risk

Gill, Paul S.↗

Organizational Conflicts of Interest Disclosure Update Statement (FY2019)

The National Technology & Engineering Solutions of Sandia, LLC (NTESS) Prime Contract department manages an organizational conflicts of interest (OCI) program that is designed to provide NTESS employees an accessible means to assist in identifying potential OCI risk and providing development support services to avoid, neutralize, or mitigate the risk. The OCI program is responsible for maintaining a regulatory infrastructure, such as corporate OCI policy and training content, to comply with NTESS's obligations set forth in prime contract clauses H-4: ORGANIZATIONAL CONFLICT OF INTEREST (OCI) — SPECIAL PROVISION and Section I Department of Energy Acquisition Regulation 952.209-72, Organizational Conflicts of Interest, Alternate I, paragraph (c)(1), Disclosure After Award. Risk identification is a key OCI program priority. Providing employees with a straight-forward, accessible and navigable mechanism to identify potential OCI risk will assist the OCI program in meeting this priority.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗

Lessons Learned With Risk Management: A Systems Engineer's Perspective

Risk management is a communications device that, when executed as an essential task, enables systems engineering to effectively balance risk across the project. Developing and baselining risks is an essential continuous task to ensure top project concerns both from bottom up and top down are being mitigated. Risk management provides the opportunity to avoid the consequence of the risk when mitigation steps start early enough. Just discussing risk with all the project flight elements during development, even if no risks are open, provides an excellent communication opportunity between systems engineering and those elements, ensuring concerns and worries have a platform for discussion. A well-managed risk identification process will identify concerns that are serious but not being clearly communicated, and it will enable mitigation of those potential problems before they cause a failure. Effective risk management requires considerable time and effort, but that effort will save time and money across the development. Risk management must be frequent enough to be useful and in depth enough to bring out emerging issues. It also requires a trusting relationship between the lead systems engineer and element and/or subsystem leads. The discussions need to be with the right number of individuals (typically a handful) and the right duration in time (typically an hour a month). Outside of these risk working groups, there is a formal management process to input, status, and disposition risks, and a monthly Risk Management Board meeting where key project stakeholders are informed. This paper provides good guidance on effective risk management from a systems engineering perspective and provides project lessons learned from the NASA spaceflight missions NICER, Landsat 9, LRO, and OSIRIS-REx to demonstrate the effectiveness of risk management.

Lessons Learned↗

Lessons Learned With Risk Management: A Systems Engineer’s Perspective

Risk management is a communications device that, when executed as an essential task, enables systems engineering to effectively balance risk across the project. Developing and baselining risks is an essential continuous task to ensure top project concerns both from bottom up and top down are being mitigated. Risk management provides the opportunity to avoid the consequence of the risk when mitigation steps start early enough. Just discussing risk with all the project flight elements during development, even if no risks are open, provides an excellent communication opportunity between systems engineering and those elements, ensuring concerns and worries have a platform for discussion. A well-managed risk identification process will identify concerns that are serious but not being clearly communicated, and it will enable mitigation of those potential problems before they cause a failure. Effective risk management requires considerable time and effort, but that effort will save time and money across the development. Risk management must be frequent enough to be useful and in depth enough to bring out emerging issues. It also requires a trusting relationship between the lead systems engineer and element and/or subsystem leads. The discussions need to be with the right number of individuals (typically a handful) and the right duration in time (typically an hour a month). Outside of these risk working groups, there is a formal management process to input, status, and disposition risks, and a monthly Risk Management Board meeting where key project stakeholders are informed. This paper provides good guidance on effective risk management from a systems engineering perspective and provides project lessons learned from the NASA spaceflight missions NICER, Landsat 9, LRO, and OSIRIS-REx to demonstrate the effectiveness of risk management.

Lessons Learned↗

Continuous Risk Management

Risk identification is an ongoing activity that takes place during the routine project work flow. Project activities such as programmatic and technical meetings, telecons, reviews, and other forms of communication often bring to light project risks. When this occurs, we record and analyze the risk on a Risk Information Sheet. This process helps the project team identify and cope with project risks throughout the life of the project.

Sabelhaus, Phil↗