SEARCH · Search NASA

Results for “Critical Function Assurance”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

104 records · Page 6

All sources NASA NTRS DOE OSTI

NASA NTRS2006

CCSDS Time-Critical Onboard Networking Service

The Consultative Committee for Space Data Systems (CCSDS) is developing recommendations for communication services onboard spacecraft. Today many different communication buses are used on spacecraft requiring software with the same basic functionality to be rewritten for each type of bus. This impacts on the application software resulting in custom software for almost every new mission. The Spacecraft Onboard Interface Services (SOIS) working group aims to provide a consistent interface to various onboard buses and sub-networks, enabling a common interface to the application software. The eventual goal is reusable software that can be easily ported to new missions and run on a range of onboard buses without substantial modification. The system engineer will then be able to select a bus based on its performance, power, etc and be confident that a particular choice of bus will not place excessive demands on software development. This paper describes the SOIS Intra-Networking Service which is designed to enable data transfer and multiplexing of a variety of internetworking protocols with a range of quality of service support, over underlying heterogeneous data links. The Intra-network service interface provides users with a common Quality of Service interface when transporting data across a variety of underlying data links. Supported Quality of Service (QoS) elements include: Priority, Resource Reservation and Retry/Redundancy. These three QoS elements combine and map into four TCONS services for onboard data communications: Best Effort, Assured, Reserved, and Guaranteed. Data to be transported is passed to the Intra-network service with a requested QoS. The requested QoS includes the type of service, priority and where appropriate, a channel identifier. The data is de-multiplexed, prioritized, and the required resources for transport are allocated. The data is then passed to the appropriate data link for transfer across the bus. The SOIS supported data links may inherently provide the quality of service support requested by the intra-network layer. In the case where the data link does not have the required level of support, the missing functionality is added by SOIS. As a result of this architecture, re-usable software applications can be designed and used across missions thereby promoting common mission operations. In addition, the protocol multiplexing function enables the blending of multiple onboard networks. This paper starts by giving an overview of the SOIS architecture in section 11, illustrating where the TCONS services fit into the overall architecture. It then describes the quality of service approach adopted, in section III. The prototyping efforts that have been going on are introduced in section JY. Finally, in section V the current status of the CCSDS recommendations is summarized.

Parkes, Steve↗

NASA NTRS2015

Fault Management Architectures and the Challenges of Providing Software Assurance

The satellite systems Fault Management (FM) is focused on safety, the preservation of assets, and maintaining the desired functionality of the system. How FM is implemented varies among missions. Common to most is system complexity due to a need to establish a multi-dimensional structure across hardware, software and operations. This structure is necessary to identify and respond to system faults, mitigate technical risks and ensure operational continuity. These architecture, implementation and software assurance efforts increase with mission complexity. Because FM is a systems engineering discipline with a distributed implementation, providing efficient and effective verification and validation (VV) is challenging. A breakout session at the 2012 NASA Independent Verification Validation (IVV) Annual Workshop titled VV of Fault Management: Challenges and Successes exposed these issues in terms of VV for a representative set of architectures. NASA's IVV is funded by NASA's Software Assurance Research Program (SARP) in partnership with NASA's Jet Propulsion Laboratory (JPL) to extend the work performed at the Workshop session. NASA IVV will extract FM architectures across the IVV portfolio and evaluate the data set for robustness, assess visibility for validation and test, and define software assurance methods that could be applied to the various architectures and designs. This work focuses efforts on FM architectures from critical and complex projects within NASA. The identification of particular FM architectures, visibility, and associated VVIVV techniques provides a data set that can enable higher assurance that a satellite system will adequately detect and respond to adverse conditions. Ultimately, results from this activity will be incorporated into the NASA Fault Management Handbook providing dissemination across NASA, other agencies and the satellite community. This paper discusses the approach taken to perform the evaluations and preliminary findings from the research including identification of FM architectures, visibility observations, and methods utilized for VVIVV.

Fault Management↗

NASA NTRS2015

Fault Management Architectures and the Challenges of Providing Software Assurance

Fault Management (FM) is focused on safety, the preservation of assets, and maintaining the desired functionality of the system. How FM is implemented varies among missions. Common to most missions is system complexity due to a need to establish a multi-dimensional structure across hardware, software and spacecraft operations. FM is necessary to identify and respond to system faults, mitigate technical risks and ensure operational continuity. Generally, FM architecture, implementation, and software assurance efforts increase with mission complexity. Because FM is a systems engineering discipline with a distributed implementation, providing efficient and effective verification and validation (V&V) is challenging. A breakout session at the 2012 NASA Independent Verification & Validation (IV&V) Annual Workshop titled "V&V of Fault Management: Challenges and Successes" exposed this issue in terms of V&V for a representative set of architectures. NASA's Software Assurance Research Program (SARP) has provided funds to NASA IV&V to extend the work performed at the Workshop session in partnership with NASA's Jet Propulsion Laboratory (JPL). NASA IV&V will extract FM architectures across the IV&V portfolio and evaluate the data set, assess visibility for validation and test, and define software assurance methods that could be applied to the various architectures and designs. This SARP initiative focuses efforts on FM architectures from critical and complex projects within NASA. The identification of particular FM architectures and associated V&V/IV&V techniques provides a data set that can enable improved assurance that a system will adequately detect and respond to adverse conditions. Ultimately, results from this activity will be incorporated into the NASA Fault Management Handbook providing dissemination across NASA, other agencies and the space community. This paper discusses the approach taken to perform the evaluations and preliminary findings from the research.

Fault Management↗

DOE OSTI2024

Synthesis of Correct Digital Controller Models from Specifications by Model Transformation (21-0320)

The design of high consequence controllers (in weapons systems, autonomy, etc.) that do what they are supposed to do is a significant challenge. Testing simply does not come close to meeting the requirements for assurance. Today circuit designers at Sandia (and elsewhere) typically capture the core behavior of their components using state models in tools such as STATEFLOW. They then check that their models meet certain requirements (e.g. “The system bus must not deadlock” or “both traffic lights at an intersection must not be green at the same time”) using tools called model checkers. If the model checker returns “yes” then the property is guaranteed to be satisfied by the model. However, there are several drawbacks to this industry practice: (1) there is a lot of detail to get right, this is particularly challenging when there are multiple components requiring complex coordination (2) any errors returned by the model checker have to be traced back through the design and fixed, necessitating rework, (3) there are severe scalability problems with this approach, particularly when dealing with concurrency. All this places high demands on the designers who now face not only an accelerated schedule but also controllers of increasing complexity. This report describes a new and fundamentally different approach to the construction of safety-critical digital controllers. Instead of directly constructing a complete model and then trying to verify it, the designer can start with an initial abstract (think “sketch”) model plus the requirements, from which a correct concrete model is automatically synthesized. There is no need for post-hoc verification of required functional properties. Having tool to carry this out will significantly impact the nation’s ability to ensure the safety of high-consequence digital systems. The approach has been implemented in a prototype tool, along with a suite of examples, including ones that reflect actual problems faced by designers. Our approach operates on a variant of Statecharts developed at Sandia called Qspecs. Statecharts are a widely used formalism for developing concurrent reactive systems, supporting scalability through allowing state models containing composite states, which are the serial or parallel composition of substates which can themselves contain statecharts. Statecharts enable an incremental style of development, in which states are progressively refined to incorporate greater detail in an incremental model of software development. Our approach formulates a set of constraints from the structure of the models and the requirements and propagates these constraints to a fixpoint. The solution to the constraints is an inductive invariant along with guards on the transitions. We also show how our approach extends to implementation refinement, decomposition, composition, and elaboration. We currently handle safety requirements written in LTL (Linear Temporal Logic)

42 ENGINEERING↗

NASA NTRS2006

Advanced Technologies for Future Spacecraft Cockpits and Space-based Control Centers

The National Aeronautics and Space Administration (NASA) is embarking on a new era of Space Exploration, aimed at sending crewed spacecraft beyond Low Earth Orbit (LEO), in medium and long duration missions to the Lunar surface, Mars and beyond. The challenges of such missions are significant and will require new technologies and paradigms in vehicle design and mission operations. Current roles and responsibilities of spacecraft systems, crew and the flight control team, for example, may not be sustainable when real-time support is not assured due to distance-induced communication lags, radio blackouts, equipment failures, or other unexpected factors. Therefore, technologies and applications that enable greater Systems and Mission Management capabilities on-board the space-based system will be necessary to reduce the dependency on real-time critical Earth-based support. The focus of this paper is in such technologies that will be required to bring advance Systems and Mission Management capabilities to space-based environments where the crew will be required to manage both the systems performance and mission execution without dependence on the ground. We refer to this concept as autonomy. Environments that require high levels of autonomy include the cockpits of future spacecraft such as the Mars Exploration Vehicle, and space-based control centers such as a Lunar Base Command and Control Center. Furthermore, this paper will evaluate the requirements, available technology, and roadmap to enable full operational implementation of onboard System Health Management, Mission Planning/re-planning, Autonomous Task/Command Execution, and Human Computer Interface applications. The technology topics covered by the paper include enabling technology to perform Intelligent Caution and Warning, where the systems provides directly actionable data for human understanding and response to failures, task automation applications that automate nominal and Off-nominal task execution based on human input or integrated health state-derived conditions. Shifting from Systems to Mission Management functions, we discuss the role of automated planning applications (tactical planning) on-board, which receive data from the other cockpit automation systems and evaluate the mission plan against the dynamic systems and mission states and events, to provide the crew with capabilities that enable them to understand, change, and manage the timeline of their mission. Lastly, we discuss the role of advanced human interface technologies that organize and provide the system md mission information to the crew in ways that maximize their situational awareness and ability to provide oversight and control of aLl the automated data and functions.

Garcia-Galan, Carlos↗

NASA NTRS2015

Radiation Budget Instrument (RBI) for JPSS-2

Radiation Budget Instrument (RBI) will be one of five instruments flying aboard the JPSS-2 spacecraft, a polar-orbiting sun-synchronous satellite in Low Earth Orbit. RBI is a passive remote sensing instrument that will follow the successful legacy of the Clouds and Earth's Radiant Energy System (CERES) instruments to make measurement of Earth's short and longwave radiation budget. The goal of RBI is to provide an independent measurement of the broadband reflected solar radiance and Earth's emitted thermal radiance by using three spectral bands (Shortwave, Longwave, and Total) that will have the same overlapped point spread function (PSF) footprint on Earth. To ensure precise NIST-traceable calibration in space the RBI sensor is designed to use a visible calibration target (VCT), a solar calibration target (SCT), and an infrared calibration target (ICT) containing phase change cells (PCC) to enable on-board temperature calibration. The VCT is a thermally controlled integrating sphere with space grade Spectralon covering the inner surface. Two sides of the sphere will have fiber-coupled laser diodes in the UV to IR wavelength region. An electrical substitution radiometer on the integrating sphere will monitor the long term stability of the sources and the possible degradation of the Spectralon in space. In addition the radiometric calibration operations will use the Spectralon diffusers of the SCT to provide accurate measurements of Solar degradation. All those stable on-orbit references will ensure that calibration stability is maintained over the RBI sensor lifetime. For the preflight calibration the RBI will view five calibration sources - two integrating spheres and three CrIS (Cross-track Infrared Sounder ) -like blackbodies whose outputs will be validated with NIST calibration approach. Thermopile are the selected detectors for the RBI. The sensor has a requirement to perform lunar calibration in addition to solar calibration in space in a way similar to CERES instruments approach. To monitor climate change and to get stable and traceable results, it is critical to assure stable calibration over instrument lifetime.

Georgieva, Elena↗

NASA NTRS2014

Application of Fault Management Theory to the Quantitative Selection of a Launch Vehicle Abort Trigger Suite

The theory of System Health Management (SHM) and of its operational subset Fault Management (FM) states that FM is implemented as a "meta" control loop, known as an FM Control Loop (FMCL). The FMCL detects that all or part of a system is now failed, or in the future will fail (that is, cannot be controlled within acceptable limits to achieve its objectives), and takes a control action (a response) to return the system to a controllable state. In terms of control theory, the effectiveness of each FMCL is estimated based on its ability to correctly estimate the system state, and on the speed of its response to the current or impending failure effects. This paper describes how this theory has been successfully applied on the National Aeronautics and Space Administration's (NASA) Space Launch System (SLS) Program to quantitatively estimate the effectiveness of proposed abort triggers so as to select the most effective suite to protect the astronauts from catastrophic failure of the SLS. The premise behind this process is to be able to quantitatively provide the value versus risk trade‐off for any given abort trigger, allowing decision makers to make more informed decisions. All current and planned crewed launch vehicles have some form of vehicle health management system integrated with an emergency launch abort system to ensure crew safety. While the design can vary, the underlying principle is the same: detect imminent catastrophic vehicle failure, initiate launch abort, and extract the crew to safety. Abort triggers are the detection mechanisms that identify that a catastrophic launch vehicle failure is occurring or is imminent and cause the initiation of a notification to the crew vehicle that the escape system must be activated. While ensuring that the abort triggers provide this function, designers must also ensure that the abort triggers do not signal that a catastrophic failure is imminent when in fact the launch vehicle can successfully achieve orbit. That is, the abort triggers must have low false negative rates to be sure that real crew‐threatening failures are detected, and also low false positive rates to ensure that the crew does not abort from non‐crew‐threatening launch vehicle behaviors. The analysis process described in this paper is a compilation of over six years of lessons learned and refinements from experiences developing abort triggers for NASA's Constellation Program (Ares I Project) and the SLS Program, as well as the simultaneous development of SHM/FM theory. The paper will describe the abort analysis concepts and process, developed in conjunction with SLS Safety and Mission Assurance (S&MA) to define a common set of mission phase, failure scenario, and Loss of Mission Environment (LOME) combinations upon which the SLS Loss of Mission (LOM) Probabilistic Risk Assessment (PRA) models are built. This abort analysis also requires strong coordination with the Multi‐Purpose Crew Vehicle (MPCV) and SLS Structures and Environments (STE) to formulate a series of abortability tables that encapsulate explosion dynamics over the ascent mission phase. The design and assessment of abort conditions and triggers to estimate their Loss of Crew (LOC) Benefits also requires in‐depth integration with other groups, including Avionics, Guidance, Navigation and Control(GN&C), the Crew Office, Mission Operations, and Ground Systems. The outputs of this analysis are a critical input to SLS S&MA's LOC PRA models. The process described here may well be the first full quantitative application of SHM/FM theory to the selection of a sensor suite for any aerospace system.

Lo, Yunnhon↗

NASA NTRS2020

Building a standardized Observing System Simulation Experiment (OSSE) framework for Mars

We advocate that the Decadal Survey recommends the NASA Science Mission Directorate to develop a rigorous Observing System Simulation Experiment (OSSE) framework for Mars, to optimize future atmospheric observations. Atmospheric conditions on Mars are a potential hazard source for landing missions. Errors in the estimates of atmospheric density profiles, inadequate knowledge of wind vertical structure and dust concentration as a function of height are likely causes of uncertainty at the landing site on the order of kilometers. An operational real-time weather forecasting capability for Mars would reduce such uncertainties, carrying enormous benefits to future robotic missions, and would be an invaluable prerequisite for human missions.A real-time forecasting capability relies upon three fundamental components: a critical mass of observing systems, a data assimilation system (DAS), and a global forecast model. The DAS allows the model to ingest the data effectively, optimizing the observational information content,and transforming them into a gridded representation of the atmosphere at a given time, called an ‘analysis’. The analysis is the best estimate of the atmospheric state for that time, and also represents a set of ‘initial conditions’ from which a global model can be initialized, to predict a future state of the atmosphere. The connection between analysis and forecast represents the foundation of modern weather forecasting. However, from the point of view of a forecast system,not all observations are equally impactful, partially because of the problem of “observational error correlation”, one important research topic in data assimilation development. For the Earth, partly due to the spontaneous and deregulated development of observations and forecast capabilities worldwide for more than half a century,the use of observations in contemporary operational forecast systems is suboptimal, with many potentially useful data being underutilized. On the contrary, Mars atmospheric scientists are in the unique situation of designing the next-generation observing systems by learning from the experience gathered on the Earth, so as to assure that the future instruments are specifically optimized to give the maximum benefit to a future weather forecast capability.An immensely powerful tool that has been firmly established by atmospheric scientists on the Earth is represented by a properly designed OSSE framework. A realistic OSSE framework cannot only quantify the benefit of future data types, be them surface based or space borne, but can also help design and optimize an entire observational network. Furthermore, OSSEs can provide deep insights into an atmosphere’s behavior, by addressing conceptual problems of its intrinsic predictability and delineating the regions or features of the atmosphere which are more sensitive to additional data and would benefit from a denser sampling. The difficulties posed by OSSEs are fundamentally different for Earth and Mars. For Earth, the enormous data volume imposes a tremendous constraint on any innovation in the observing systems: it is very hard for a single sensor to impact the skill. For Mars, the problem is the opposite: almost any additional instrument will exert some impact. However, OSSEs can help to evaluate the cost/benefit for every sensor and suggest optimal data configuration and density.The purpose of this white paper is to provide an introduction to a rigorously designed OSSE framework, explain the underlying problems and challenges, and engage the Mars community to collaborate with Earth Atmospheric scientists in order to develop a joint-OSSE framework for Mars with the largest consensual basis possible. An OSSE infrastructure would increase the understanding of the Martian atmosphere, would help NASA to optimize instrument specifications and orbit choice, providing the maximium benefit for a given expenditure of resources, and could even help establishing a roadmap for a future real-time weather forecasting capability.

Oreste Reale↗

NASA NTRS1964

Biomedical and Human Factors Requirements for a Manned Earth Orbiting Station

The primary objective of this study is to determine which biomedical and human factors measurements must be made aboard a space station to assure adequate evaluation of the astronaut's health and performance during prolonged space flights. The study has employed, where possible, a medical and engineering systems analysis to define the pertinent life sciences and space station design parameters and their influence on a measurement program. The major areas requiring evaluation in meeting the study objectives include a definition of the space environment, man's response to the environment, selection of measurement and data management techniques, experimental program, space station design requirements, and a trade-off analysis with final recommendations. The space environment factors that are believed to have a significant effect on man were evaluated. This includes those factors characteristic of the space environment (e. g. weightlessness, radiation) as well as those created within the space station (e. g. toxic contaminants, capsule atmosphere). After establishing the general features of the environment, an appraisal was made of the anticipated response of the astronaut to each of these factors. For thoroughness, the major organ systems and functions of the body were delineated, and a determination was made of their anticipated response to each of the environmental categories. A judgment was then made on the medical significance or importance of each response, which enabled a determination of which physiological and psychological effects should be monitored. Concurrently, an extensive list of measurement techniques and methods of data management was evaluated for applicability to the space station program. The various space station configurations and design parameters were defined in terms of the biomedical and human factors requirements to provide the measurements program. Research design of experimental programs for various station configurations, mission durations, and crew sizes were prepared, and, finally, a trade-off analysis of the critical variables in the station planning was completed with recommendations to enhance the confidence in the measurement program.

EARTH ORBIT↗

NASA NTRS2005

Taking the Risk Out of Risk Assessment

The ability to understand risks and have the right strategies in place when risky events occur is essential in the workplace. More and more organizations are being confronted with concerns over how to measure their risks or what kind of risks they can take when certain events transpire that could have a negative impact. NASA is one organization that faces these challenges on a daily basis, as effective risk management is critical to the success of its missions especially the Space Shuttle missions. On July 29, 1996, former NASA Administrator Daniel Goldin charged NASA s Office of Safety and Mission Assurance with developing a probabilistic risk assessment (PRA) tool to support decisions on the funding of Space Shuttle upgrades. When issuing the directive, Goldin said, "Since I came to NASA [in 1992], we've spent billions of dollars on Shuttle upgrades without knowing how much they improve safety. I want a tool to help base upgrade decisions on risk." Work on the PRA tool began immediately. The resulting prototype, the Quantitative Risk Assessment System (QRAS) Version 1.0, was jointly developed by NASA s Marshall Space Flight Center, its Office of Safety and Mission Assurance, and researchers at the University of Maryland. QRAS software automatically expands the reliability logic models of systems to evaluate the probability of highly detrimental outcomes occurring in complex systems that are subject to potential accident scenarios. Even in its earliest forms, QRAS was used to begin PRA modeling of the Space Shuttle. In parallel, the development of QRAS continued, with the goal of making it a world-class tool, one that was especially suited to NASA s unique needs. From the beginning, an important conceptual goal in the development of QRAS was for it to help bridge the gap between the professional risk analyst and the design engineer. In the past, only the professional risk analyst could perform, modify, use, and perhaps even adequately understand PRA. NASA wanted to change this by developing a PRA tool that would be friendlier, more understandable, and more useful to the broader engineering community. This concept ultimately led to the look, feel, and functionality that QRAS has today.

Source record↗

NASA NTRS2024

Testing of Advanced Capabilities to Enable In-time Safety Management and Assurance for Future Flight Operations

In order to refine an initial Concept of Operations, explore Concepts of Use, and expose/validate requirements for future In-Time Aviation Safety Management Systems (IASMS), testing architectures were created, along with a set of capabilities and underlying information exchange protocols. These systems were conceived and developed based on hazards associated with two envisioned urban area flight domains: (1) highly autonomous small uncrewed aerial systems (sUAS) operating at low altitudes, and (2) highly autonomous air taxis. The initial scope of this development is described in [1]; this report provides an update, focusing on the subsequent developments and test activities. As stated in [1], it is important to note that there are many capabilities already in use by the industry (or soon to be in use) that will play critical roles in future IASMS designs. Those reported here were developed to address a gap in the current state-of-the-art regarding specific hazards/risks, and/or to allow for investigation of the interplay between and across hazard types — particularly regarding how overall safety risk can be reduced or managed effectively. Results of testing and development activities are organized by the operational phase wherein a particular capability would be employed (i.e., preflight, in-flight, and post-flight/off-line). Pre-flight: A set of capabilities were developed to help mitigate safety risk prior to flight (e.g., during flight and mission planning). Results of testing summarize (1) validation activities to raise the Technology Readiness Level (TRL) and (2) evaluation activities where the capabilities were applied to flight/mission planning procedures and used by operators/pilots. For the latter, flight plans were automatically assessed, and operators/pilots were notified of hazardous flight segments so as to enable adjustment of the flight plan and re-evaluation, and/or to better inform go/no-go decisions. Capabilities addressed hazards associated with power consumption, third-party risk, wind, navigation system performance, radiofrequency interference, and proximity to geo-spatial threats (e.g., buildings, trees, and no-fly zones). In-flight: Flight experiments tested capabilities that detect and respond to hazards encountered during flight. In the first series, safety hazards were monitored and assessed onboard, and system-generated mitigation maneuvers were recorded (but not acted upon by the vehicle). In the second series, mitigation maneuver commands directed the aircraft in response to safety hazards (i.e., auto-mitigation). The sUAS used for testing is described in full, as is the test architecture, which included commercial avionics, research avionics, and onboard software designed to detect, assess, and respond to hazards. The onboard system was designed as a run-time assurance framework, consistent with [2] and supportive of both supervisory and automated modes. The primary functions included: real-time risk assessment (RTRA), auto-pilot monitoring, constraint monitoring, and contingency select/triggering. RTRA performs integrated risk assessment considering data from several hazard-related monitors (e.g., battery, motors, navigation, communications, population density, and loss-of-control). Post-flight/off-line: Data monitored and recorded during flights can enable IASMS capabilities that execute after flights have completed (or “off-line”). These include: (1) the ability to identify anomalies and trends that may only be observable when comparing data spanning a number of similar flights; (2) the ability to update and validate pre-flight and in-flight capabilities and any underlying models to improve their performance; (3) the ability to report anomalies/off-nominals that may indicate design changes or maintenance actions are needed; and (4) the ability for humans involved in operations to report safety-relevant observations to help in understanding the flight data and/or the operational context of a flight. Progress on three such capabilities is summarized; the first investigates anomaly detection given a limited set of flight logs and applies an approach previously used for space operations. The second explores what could be identified using a larger set of flight logs, including from web-based forums where flight logs are posted by sUAS autopilot users. The third creates a new means of collecting information on UAS incidents and accidents via the Aviation Safety Reporting System (ASRS).

sUAS↗

NASA NTRS2022

Assurance Equations: A Cost and Criticality Model for Optimizing Quality Assurance Surveillance

The cost of quality vs cost of failure correction has been a long-running topic of discussion within the Aerospace community. It leads directly to concepts of “risk tolerance”, and risk-based decision-making. It would be valuable if there was a way to compute the optimal investment in customer-executed quality assurance activities using defect significance with respect to performance objectives, the activities’ defect detection effectiveness, and the cost-penalty for late discovery of impactful defects. This optimization is particularly of interest to projects whose budget constraints significantly limit their risk management options.The cost to fix defects (i.e., failure correction) escalates as the project matures. There have been studies attempting to determine the relative cost of fixing defects discovered during various phases of a project life cycle with important implications, all of which suggest growth factors are large. The commonly referred to 1:10:100 rule represents a cost multiplier for repair/rework across the Design to Fab to Test hardware development phases. Cost premiums for QA activities also accumulate when they are treated as mandatory (due to schedule drag) or are performed later than their assigned phase.This paper describes the modeling of development phase -dependencies in the conduct of typical customer-executed quality assurance activities. Our initial modeling encompasses:• Distinct phases of the production lifecycle• Multiple kinds of Defects, each with some a-priori likelihood of being present• Each defect’s impact on performance Objectives for a type of hardware• The cost and efficacy of assurance techniques at detecting such Defects• The costs of fixing those Defects detected in a given phase of the production lifecycleThe model captures assurance activities’ abilities to Detect defects. Upon detection it is assumed that the Defect is immediately fixed. Defects that “escape” detection by some activity may thereafter be detected by a later activity, but by then the cost of fixing the Defect may have escalated. Defects are related to the performance Objectives they would detract from, were those Defects to remain present in the operating system.We have constructed and are exploring, a model that relates the importance of hardware system elements to mission objectives, the impact of types of Defects on those hardware types, the cost of customer-executed assurance activities (i.e., supplier controls) and their effectiveness towards reducing an impactful quality escape, and the cost of Defect correction across production phase. We describe the approach taken to select the key model aspects, why they are relevant to our NASA mission, and our efforts to populate it with relevant and contemporary data. We use a notional example to illustrate model design and function.

Plante, Jeannette↗

NASA NTRSDate not supplied

Informing New Concepts for UAS and Autonomous System Safety Management using Disaster Management and First Responder Scenarios

As emerging flight operations become more prevalent and increasingly automated and distributed, the capabilities for managing safety of vehicles and operations will also need to evolve. To address this challenge, the National Academies has envisioned an In-Time Aviation Safety Management System (IASMS) capability for a wide range of aviation operations including current commercial operations as well as new entrants envisioned with advanced air mobility (AAM). The suite of IASMS services, functions, and capabilities (SFCs) would be implemented in a federated approach and would address trends as well as individual operations. Through predictive modeling and data analysis, IASMS is envisioned to identify arising risks so that they can be mitigated, in-time, before a safety incident occurs. IASMS and its requisite set of SFCs must leverage a wide range of information to perform. To better understand these new needs, FSF worked with the aviation and humanitarian communities to develop and validate scenarios that include traditional aviation operations and UAS operations intermingled as they are deployed for disaster management and first responder (DMFR) situations. The three scenarios developed include: • Post Natural disaster response, such as a hurricane, involving multiple parties utilizing traditional aviation and UAS to support rescue operations, surveil damage, and locate survivors needing assistance. • Wildfire fighting in remote locations with traditional aircraft for transport and fire-retardant delivery combined with UAS for surveillance of fire locations as well as to track individual firefighter locations. • Medical Operations and AAM in Urban Environments including passenger-carrying helicopters and AAM vehicles, medical missions (such as transport of radio-pharmaceuticals), and other UAS delivery operations (such as the delivery of defibrillators). Each scenario was developed and validated by representatives with expertise in humanitarian operations, urban and rural emergency response, air traffic management, UAS operations, and traditional flight operations. The scenario definitions address roles and responsibilities of individual actors, the appropriate utilization of UAS, and the actions taken by those actors to appropriately manage risks associated with the mission and environment. The risks to aviation traffic and to people on the ground explored included potential risks arising from incompatibilities in calculating reference altitudes (eg, differing uses of AGL, MSL, barometric, or GPS-derived values), loss of command and control (C2) communications, rapid changes in weather and winds, and physical interference. For each risk, IASMS SFCs were postulated in the context of monitoring services, risk assessment capabilities, and identifying appropriate mitigation strategies. The identified SFC capabilities were envisioned from known services postulated for IASMS and for UTM. For these unique environments, IASMS SFCs are needed to address conditions such as hazardous payloads, micro-climates and urban canyons, and the need to keep uninvolved air traffic out of the area where DMFR operations are being conducted. The second phase of analysis focused on inferring the specific information needs and the SFCs for IASMS, utilizing a structure of 16 information classes to organize requirements. For each of the risks identified in the workshops, it was postulated what data sources would be necessary to monitor critical aspects of the risk (eg, surrounding air traffic, ground population, terrain, etc). to be directly measured as well as data that would be derived, which implies additional SFCs for different actors to understand what information would likely be exchanged between parties. For an IASMS to be effective, additional research is needed to develop the advanced algorithms that can address the increasingly autonomous and complex operations in differing environments and to develop means of identifying unknown risks. Looking at these scenarios highlighted a number of research issues. These include the ability to quickly "cordon off" airspace thru temporary flight restrictions (TFRs) or other means, developing clear definitions to enable automation-based algorithms for prioritizing operations, defining airspace density metrics, standardization of altitude reporting, and establishing a basis for safety data metrics definition and collection. This paper seeks to outline the development of an IASMS in the context of the DMFR scenarios and resulting demonstrations. Utilizing this contextual approach, NASA will generate recommendations for an assured safety framework for AAM operations that enables AAM operations to safely access the NAS.

In Time Aviation Safety Management System↗

NASA NTRSDate not supplied

An Approach for Defining IASMS Services, Functions, and Capabilities

Assuring safety in the NAS with the inclusion of new entrants, such as Advanced Air Mobility (AAM), will require overcoming unique safety challenges that result from combining innovative technologies with novel airspace concepts for moving people and cargo using autonomous vehicles. The focus of the In-time Aviation Safety Management System (IASMS) is to overcome AAM’s safety assurance challenges. The IASMS Concept of Operations (ConOps) describes an interconnected set of services, functions, and capabilities (SFCs) designed to manage operational risks, identify unknown risks, and inform system designs. This paper describes an approach for defining SFCs based on technology trends in research, assessment of known and unknown risks in voluntary safety reports, and causal and contributing factors in aviation accidents and incidents. This approach would identify potential SFCs that further expand the Monitor, Assess, and Mitigate (M-A-M) functionality that represents the enabling framework of the IASMS. Safety implications that will result from integration of AAM in the transformation of the National Airspace System (NAS) were addressed in National Academies committees reports on AAM and IASMS. Development of a ConOps for IASMS was a top recommendation and can be represented as a reframing of safety assurance that builds on real-time alerting such as the Traffic Alert and Collision Avoidance System, and adds the more encompassing in-time temporal parameter in recognition of the different timelines for collecting and assessing safety data for risk mitigations. For example, mining for safety trends from data sources such as the Aviation Safety Information Analysis and Sharing system occurs over a longer time period. Research on AAM operations poses that SFCs can be designed to monitor the safety margin appropriate for AAM including with regards to the distance between current flight parameters and nominal ideal conditions. These in-time comparisons will become more complex as the density of operations increases at least in certain areas and can include planned and actual 4D trajectory, and in-time comparisons having implications on conflict modeling and prediction including expected and actual departure time, fix/waypoint crossing times, and arrival time. These comparisons would be integrated as part of SFCs that redefine and inform new safety margin. An increased safety margin improves management of operational risks while reducing the potential for anomalies. An increased safety margin also has implications for operator confidence in the certainty of its operations and trust in automation. Technology trends in research could be used to refine existing SFCs and define needs for additional SFCs that provide safety improvements to the design and operation of vehicles, airspace design, and operator performance requirements. NASA is developing innovative approaches to safeguard against major accidents and incidents that have occurred in the NAS and those anticipated with the inclusion of envisioned AAM operations. The innovations use operational performance data to monitor, detect, and predict flight variations exceeding safe nominal patterns, such as would be caused by navigational error, severe weather complications, or hijacking of UAS controls. These innovative approaches have high potential to prevent accidents and incidents in the new AAM era. It is anticipated that elements of the innovations will evolve into SFCs for the IASMS. Voluntary safety reports can be monitored to identify anomalies related to design or operational performance risks. Reports could be periodically monitored and assessed for specific topics. Reports might serve as weak signals or precursors indicative of emergent risk such as when combined with other safety information. The architecture could include SFCs that are based on voluntary safety reports recognizing the periodic temporal nature of data analysis. As previously mentioned, aviation accidents with their causal and contributing precursors can inform the need for SFCs in the IASMS. Accidents and incidents at San Francisco International Airport such as Asiana 214 and Air Canada 759 illustrate how combinations of different factors lead to increased risk. These types of precursors and different factors have implications on the types of SFCs that could be needed to monitor and manage different sources and types of design and operational risk. Continuing to assure the safety of AAM as designs and operations gain in complexity can be accompanied by defining SFCs that also increase in complexity. These SFCs can leverage information from findings and recommendations synthesized across on-going research, voluntary safety reports, and accident and incident reports. These SFCs can serve to refine accuracy of algorithms and resolve limitations with current practices. The IASMS architecture represents the framework for the SFCs and their critical role in safety assurance.

In-Time Aviation Safety Management System↗