SEARCH · Engineering Papers

Results for “contingency analysis”

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.

226 records · Page 13

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

High-Pressure Oxygen Dryer (HPOD) FY 2023 Trade Study and Market Survey

A reliable source of dry, high-pressure oxygen is needed for future lunar missions to support nominal and contingency operations on the Surface Habitat (SH) and the Pressurized Rover (PR) in future Gateway missions. A High-Pressure Oxygen Dryer (HPOD) is needed to support potential use of primary oxygen generation systems, the High-Pressure Oxygen Generation Assembly (HPOGA) and the Skyre EOC, by drying the wet oxygen exiting the systems. The objective of this paper is to perform an architecture trade study and market survey of options to dry a continuous stream of 45°C, 4000 PSIG oxygen containing ~ 500 ppm H2O (dew point 52°C) down to < 7 ppm H2O (dew point -15°C) for both the 28-day and 365-day timeframe. A total of seven different technologies were identified as potential dryer candidates during the market survey, relying on one of three principles, adsorption, filtration, and cooling. During the sizing and trade study, it was found that several of the technologies aren’t sufficient for the extreme conditions and were eliminated. In the end, a single-use throw away adsorption bed traded the best for single mission use, while a pressure regenerative adsorption bed traded the best for a multiple mission scenario. The results of this analysis are intended to influence future design work for high-pressure oxygen drying applications.

High Pressure Oxygen↗

NASA NTRSDate not supplied

High-Pressure Oxygen Dryer (HPOD) FY 2023 Trade Study and Market Survey

A reliable source of dry, high-pressure oxygen is needed for future lunar missions to support nominal and contingency operations on the Surface Habitat (SH) and the Pressurized Rover (PR) in future Gateway missions. A High-Pressure Oxygen Dryer (HPOD) is needed to support potential use of primary oxygen generation systems, the High-Pressure Oxygen Generation Assembly (HPOGA) and the Skyre EOC, by drying the wet oxygen exiting the systems. The objective of this paper is to perform an architecture trade study and market survey of options to dry a continuous stream of 45°C, 4000 PSIG oxygen containing ~ 500 ppm H 2 O (dew point 52°C) down to < 7 ppm H 2 O (dew point -15°C) for both the 28-day and 365-day timeframe. A total of seven different technologies were identified as potential dryer candidates during the market survey, relying on one of three principles, adsorption, filtration, and cooling. During the sizing and trade study, it was found that several of the technologies aren’t sufficient for the extreme conditions and were eliminated. In the end, a single-use throw away adsorption bed traded the best for single mission use, while a pressure regenerative adsorption bed traded the best for a multiple mission scenario. The results of this analysis are intended to influence future design work for high-pressure oxygen drying applications.

High Pressure Oxygen↗

NASA NTRS1992

Role of automation in the ACRV operations

The Assured Crew Return Vehicle (ACRV) will provide the Space Station Freedom with contingency means of return to earth (1) of one disabled crew member during medical emergencies, (2) of all crew members in case of accidents or failures of SSF systems, and (3) in case of interruption of the Space Shuttle flights. A wide range of vehicle configurations and system approaches are currently under study. The Program requirements focus on minimizing life cycle costs by ensuring simple operations, built-in reliability and maintainability. The ACRV philosophy of embedded operations is based on maximum use of existing facilities, resources and processes, while minimizing the interfaces and impacts to the Space Shuttle and Freedom programs. A preliminary integrated operations concept based on this philosophy and covering the ground, flight, mission support, and landing and recovery operations has been produced. To implement the ACRV operations concept, the underlying approach has been to rely on vehicle autonomy and automation, to the extent possible. Candidate functions and processes which may benefit from current or near-term automation and robotics technologies are identified. These include, but are not limited to, built-in automated ground tests and checkouts; use of the Freedom and the Orbiter remote manipulator systems, for ACRV berthing; automated passive monitoring and performance trend analysis, and periodic active checkouts during dormant periods. The major ACRV operations concept issues as they relate to the use of automation are discussed.

Sepahban, S. F.↗

NASA NTRSDate not supplied

Risk Assessment of Obstacle Collision for UAVs under Off-nominal Conditions

Enabling operations of unmanned aerial vehicles (UAVs) in low-altitude airspace demands the need of robust risk monitoring framework for assessing the safety of airspace, ground structures and people. As widespread applications emerge, the need of risk assessment becomes increasingly important for UAV flights beyond visual line-of-sight, especially subjected to off-nominal conditions introduced by component failures, degraded controllability or environmental disturbances such as wind gusts in an urban canyon. From a safety perspective, collision with obstacles can be detrimental not only to the vehicle and payload, but also to the structure and people on ground. Although it is safe to assume that approved UAVs would be equipped with collision avoidance systems, risk of collision which can be predicted for a flight trajectory even before the UAV encounters any obstacle is beneficial to resolve contingencies in its decision-making under off-nominal conditions. In this paper, a framework is presented for computing the risk of collision with obstacle based on a UAV’s predicted trajectory, proximity to static and dynamic obstacles, sub-system state-of-health and external wind conditions. The conditional probability of trajectory deviation is generated using a Bayesian Belief Network (BBN) based on on-board sensor measurements. Further, a kinematic 3-DOF model is implemented to compute deviation in UAV’s trajectory subjected to one case study of off-nominal condition i.e. wind gusts. Finally, the integrated risk factor is demonstrated on real data from experimental flights of an octocopter at NASA Langley Research Center, in presence of simulated obstacles and wind conditions. The proposed approach would enable risk-informed decision making process for timely mitigation of current and future unsafe events.

Bayesian network↗

NASA NTRS2008

Scripting Module for the Satellite Orbit Analysis Program (SOAP)

This add-on module to the SOAP software can perform changes to simulation objects based on the occurrence of specific conditions. This allows the software to encompass simulation response of scheduled or physical events. Users can manipulate objects in the simulation environment under programmatic control. Inputs to the scripting module are Actions, Conditions, and the Script. Actions are arbitrary modifications to constructs such as Platform Objects (i.e. satellites), Sensor Objects (representing instruments or communication links), or Analysis Objects (user-defined logical or numeric variables). Examples of actions include changes to a satellite orbit ( v), changing a sensor-pointing direction, and the manipulation of a numerical expression. Conditions represent the circumstances under which Actions are performed and can be couched in If-Then-Else logic, like performing v at specific times or adding to the spacecraft power only when it is being illuminated by the Sun. The SOAP script represents the entire set of conditions being considered over a specific time interval. The output of the scripting module is a series of events, which are changes to objects at specific times. As the SOAP simulation clock runs forward, the scheduled events are performed. If the user sets the clock back in time, the events within that interval are automatically undone. This script offers an interface for defining scripts where the user does not have to remember the vocabulary of various keywords. Actions can be captured by employing the same user interface that is used to define the objects themselves. Conditions can be set to invoke Actions by selecting them from pull-down lists. Users define the script by selecting from the pool of defined conditions. Many space systems have to react to arbitrary events that can occur from scheduling or from the environment. For example, an instrument may cease to draw power when the area that it is tasked to observe is not in view. The contingency of the planetary body blocking the line of sight is a condition upon which the power being drawn is set to zero. It remains at zero until the observation objective is again in view. Computing the total power drawn by the instrument over a period of days or weeks can now take such factors into consideration. What makes the architecture especially powerful is that the scripting module can look ahead and behind in simulation time, and this temporal versatility can be leveraged in displays such as x-y plots. For example, a plot of a satellite s altitude as a function of time can take changes to the orbit into account.

Carnright, Robert↗

NASA NTRSDate not supplied

Preparation for an Earth Independent Medical Operations Demonstration using the Tempus ALS™ Medical Device

NASA’s exploration-class missions have severe resource constraints, long return trip durations, significant communication delays and limited resupply opportunities. Validation on the International Space Station (ISS) of medical devices that fit within Earth-Independent Medical Operations (EIMO) systems is a necessary preparation step. Key features of an EIMO medical system include: 1) technologies that support the prevention, diagnosis, and treatment of spaceflight medical events; 2) components that meet mass, volume, power and crew time/training constraints; 3) consideration of the medical skill level of the astronaut caregiver; 4) collection, storage and analysis of medical data within a central data architecture; and 5) incorporation of appropriate guidance and support tools that allow crew autonomy. The Human Research Program’s (HRP) Exploration Medical Capability (ExMC) Element and the Exploration Medical Integrated Product Team (XM-IPT) are planning an ISS technology demonstration to determine the feasibility of including a multifunctional medical device into an EIMO medical system. Demonstration Preparations: The Tempus ALS (Remote Diagnostic Technologies, Ltd., Philips Corp., Farnborough, UK) is a commercial-off-the-shelf medical device, with United States Food and Drug Administration clearance and is Conformité Européene marked in Europe. Several thousand units have been sold and are successfully operating in pre-hospital and in remote settings, such as by European Space Agency (ESA) flight surgeons and some of NASA’s commercial partners during post-flight medical operations. The Tempus ALS provides vital sign measurements such as blood pressure, electrocardiograms, heart rate, end tidal CO2, respiration rate, pulse oximetry and temperature. The device has ultrasound imaging and video laryngoscopy capabilities and has automatic or manual defibrillation modes for treating cardiac arrhythmias. It includes procedural guidance capabilities to assist in the collection of the vital sign measurements and it has various data transmission and report generation features. NASA’s HRP ExMC and XM-IPT are partnering with the ESA to demonstrate the Tempus ALS on ISS, with ESA manifesting the Tempus ALS and its accessories. ESA will compare performance of periodic health status exams and medical contingency drills performed nominally and with the Tempus ALS. NASA’s EIMO demonstration will include the use of Tempus ALS to diagnose a complaint of abdominal pain under increasingly independent circumstances. The caregiver must assess the present illness, collect vital sign measurements, and perform an abdominal ultrasound, under one of three communication situations, including real-time, with a several second delay and with a delay on the order of minutes. Expected Outcomes: Information will be gained about the feasibility, benefits, and challenges of using a multifunctional, all-in-one, medical device for medical diagnosis instead of separate devices with singular functionalities. Information will also be collected about performance differences as communication delays increase and available ground support decreases. Gaining this understanding will allow for further development of exploration medical system capabilities which takes the EIMO construct into consideration.

Beth Lewandowski↗

NASA NTRS2007

Multi-Sensor Testing for Automated Rendezvous and Docking Sensor Testing at the Flight Robotics Laboratory

The Exploration Systems Architecture defines missions that require rendezvous, proximity operations, and docking (RPOD) of two spacecraft both in Low Earth Orbit (LEO) and in Low Lunar Orbit (LLO). Uncrewed spacecraft must perform automated and/or autonomous rendezvous, proximity operations and docking operations (commonly known as AR&D). The crewed missions may also perform rendezvous and docking operations and may require different levels of automation and/or autonomy, and must provide the crew with relative navigation information for manual piloting. The capabilities of the RPOD sensors are critical to the success of the Exploration Program. NASA has the responsibility to determine whether the Crew Exploration Vehicle (CEV) contractor proposed relative navigation sensor suite will meet the requirements. The relatively low technology readiness level of AR&D relative navigation sensors has been carried as one of the CEV Project's top risks. The AR&D Sensor Technology Project seeks to reduce the risk by the testing and analysis of selected relative navigation sensor technologies through hardware-in-the-loop testing and simulation. These activities will provide the CEV Project information to assess the relative navigation sensors maturity as well as demonstrate test methods and capabilities. The first year of this project focused on a series of"pathfinder" testing tasks to develop the test plans, test facility requirements, trajectories, math model architecture, simulation platform, and processes that will be used to evaluate the Contractor-proposed sensors. Four candidate sensors were used in the first phase of the testing. The second phase of testing used four sensors simultaneously: two Marshall Space Flight Center (MSFC) Advanced Video Guidance Sensors (AVGS), a laser-based video sensor that uses retroreflectors attached to the target vehicle, and two commercial laser range finders. The multi-sensor testing was conducted at MSFC's Flight Robotics Laboratory (FRL) using the FRL's 6-DOF gantry system, called the Dynamic Overhead Target System (DOTS). The target vehicle for "docking" in the laboratory was a mockup that was representative of the proposed CEV docking system, with added retroreflectors for the AVGS. The multi-sensor test configuration used 35 open-loop test trajectories covering three major objectives: (1) sensor characterization trajectories designed to test a wide range of performance parameters; (2) CEV-specific trajectories designed to test performance during CEV-like approach and departure profiles; and (3) sensor characterization tests designed for evaluating sensor performance under more extreme conditions as might be induced during a spacecraft failure or during contingency situations. This paper describes the test development, test facility, test preparations, test execution, and test results of the multi-sensor series of trajectories.

Brewster, L.↗

NASA NTRS2008

Multi-Sensor Testing for Automated Rendezvous and Docking Sensor Testing at the Flight Robotics Lab

The Exploration Systems Architecture defines missions that require rendezvous, proximity operations, and docking (RPOD) of two spacecraft both in Low Earth Orbit (LEO) and in Low Lunar Orbit (LLO). Uncrewed spacecraft must perform automated and/or autonomous rendezvous, proximity operations and docking operations (commonly known as AR&D). The crewed missions may also perform rendezvous and docking operations and may require different levels of automation and/or autonomy, and must provide the crew with relative navigation information for manual piloting. The capabilities of the RPOD sensors are critical to the success ofthe Exploration Program. NASA has the responsibility to determine whether the Crew Exploration Vehicle (CEV) contractor-proposed relative navigation sensor suite will meet the requirements. The relatively low technology readiness level of AR&D relative navigation sensors has been carried as one of the CEV Project's top risks. The AR&D Sensor Technology Project seeks to reduce the risk by the testing and analysis of selected relative navigation sensor technologies through hardware-in-the-Ioop testing and simulation. These activities will provide the CEV Project information to assess the relative navigation sensors maturity as well as demonstrate test methods and capabilities. The first year of this project focused on a series of "pathfinder" testing tasks to develop the test plans, test facility requirements, trajectories, math model architecture, simulation platform, and processes that will be used to evaluate the Contractor-proposed sensors. Four candidate sensors were used in the first phase of the testing. The second phase of testing used four sensors simultaneously: two Marshall Space Flight Center (MSFC) Advanced Video Guidance Sensors (AVGS), a laser-based video sensor that uses retroreflectors attached to the target vehicle, and two commercial laser range finders. The multi-sensor testing was conducted at MSFC's Flight Robotics Laboratory (FRL) using the FRL's 6-DOF gantry system, called the Dynamic Overhead Target System (DOTS). The target vehicle for "docking" in the laboratory was a mockup that was representative of the proposed CEV docking system, with added retroreflectors for the AVGS.' The multi-sensor test configuration used 35 open-loop test trajectories covering three major objectives: (l) sensor characterization trajectories designed to test a wide range of performance parameters; (2) CEV-specific trajectories designed to test performance during CEV-like approach and departure profiles; and (3) sensor characterization tests designed for evaluating sensor performance under more extreme conditions as might be induced during a spacecraft failure or during contingency situations. This paper describes the test development, test facility, test preparations, test execution, and test results of the multisensor series oftrajectories

Brewster, Linda L.↗

NASA NTRS2014

Virtualization - A Key Cost Saver in NASA Multi-Mission Ground System Architecture

With science team budgets being slashed, and a lack of adequate facilities for science payload teams to operate their instruments, there is a strong need for innovative new ground systems that are able to provide necessary levels of capability processing power, system availability and redundancy while maintaining a small footprint in terms of physical space, power utilization and cooling.The ground system architecture being presented is based off of heritage from several other projects currently in development or operations at Goddard, but was designed and built specifically to meet the needs of the Science and Planetary Operations Control Center (SPOCC) as a low-cost payload command, control, planning and analysis operations center. However, this SPOCC architecture was designed to be generic enough to be re-used partially or in whole by other labs and missions (since its inception that has already happened in several cases!)The SPOCC architecture leverages a highly available VMware-based virtualization cluster with shared SAS Direct-Attached Storage (DAS) to provide an extremely high-performing, low-power-utilization and small-footprint compute environment that provides Virtual Machine resources shared among the various tenant missions in the SPOCC. The storage is also expandable, allowing future missions to chain up to 7 additional 2U chassis of storage at an extremely competitive cost if they require additional archive or virtual machine storage space.The software architecture provides a fully-redundant GMSEC-based message bus architecture based on the ActiveMQ middleware to track all health and safety status within the SPOCC ground system. All virtual machines utilize the GMSEC system agents to report system host health over the GMSEC bus, and spacecraft payload health is monitored using the Hammers Integrated Test and Operations System (ITOS) Galaxy Telemetry and Command (TC) system, which performs near-real-time limit checking and data processing on the downlinked data stream and injects messages into the GMSEC bus that are monitored to automatically page the on-call operator or Systems Administrator (SA) when an off-nominal condition is detected. This architecture, like the LTSP thin clients, are shared across all tenant missions.Other required IT security controls are implemented at the ground system level, including physical access controls, logical system-level authentication authorization management, auditing and reporting, network management and a NIST 800-53 FISMA-Moderate IT Security plan Risk Assessment Contingency Plan, helping multiple missions share the cost of compliance with agency-mandated directives.The SPOCC architecture provides science payload control centers and backup mission operations centers with a cost-effective, standardized approach to virtualizing and monitoring resources that were traditionally multiple racks full of physical machines. The increased agility in deploying new virtual systems and thin client workstations can provide significant savings in personnel costs for maintaining the ground system. The cost savings in procurement, power, rack footprint and cooling as well as the shared multi-mission design greatly reduces upfront cost for missions moving into the facility. Overall, the authors hope that this architecture will become a model for how future NASA operations centers are constructed!

Ground System Architecture↗

NASA NTRS2015

OSIRIS-REx, Returning the Asteroid Sample

This paper addresses the technical aspects of the sample return system for the upcoming Origins, Spectral Interpretation, Resource Identification, and Security-Regolith Explorer (OSIRIS-REx) asteroid sample return mission. The overall mission design and current implementation are presented as an overview to establish a context for the technical description of the reentry and landing segment of the mission.The prime objective of the OSIRIS-REx mission is to sample a primitive, carbonaceous asteroid and to return that sample to Earth in pristine condition for detailed laboratory analysis. Targeting the near-Earth asteroid Bennu, the mission launches in September 2016 with an Earth reentry date of September 24, 2023.OSIRIS-REx will thoroughly characterize asteroid Bennu providing knowledge of the nature of near-Earth asteroids that is fundamental to understanding planet formation and the origin of life. The return to Earth of pristine samples with known geologic context will enable precise analyses that cannot be duplicated by spacecraft-based instruments, revolutionizing our understanding of the early Solar System. Bennu is both the most accessible carbonaceous asteroid and one of the most potentially Earth-hazardous asteroids known. Study of Bennu addresses multiple NASA objectives to understand the origin of the Solar System and the origin of life and will provide a greater understanding of both the hazards and resources in near-Earth space, serving as a precursor to future human missions to asteroids.This paper focuses on the technical aspects of the Sample Return Capsule (SRC) design and concept of operations, including trajectory design and reentry retrieval. Highlights of the mission are included below.The OSIRIS-REx spacecraft provides the essential functions for an asteroid characterization and sample return mission: attitude control propulsion power thermal control telecommunications command and data handling structural support to ensure successful rendezvous with Bennu characterization of Bennus properties delivery of the sampler to the surface, and return of the spacecraft to the vicinity of the Earth sample collection, performed by the Touch-and-Go Sample Acquisition Mechanism (TAGSAM), to acquire a regolith sample from the surface Earth re-entry and SRC recovery. Following sample collection, OSIRIS-REx drifts away from Bennu until the Asteroid Departure Maneuver is commanded on March 4, 2021, sending OSIRIS-REx on a ballistic return cruise to Earth. No additional large deterministic maneuvers are required to return the SRC to Earth. During the cruise, tracking and trajectory correction maneuvers (TCMs) are performed as necessary to precisely target the entry corridor. As OSIRIS-REx approaches Earth, the reentry plans are reviewed starting about a year before arrival, and preparations begin. The spacecraft is targeted away from the Earth until 7 days before entry. The final two trajectory correction maneuvers bring the spacecraft on target toward the Utah Test and Training Range (UTTR), with sufficient time for contingency resolution. The SRC releases 4 hours prior to atmospheric entry interface and, using the Stardust capsule heritage design, employs a traditional drogue and main parachute descent system for a soft touchdown.

reentry↗