Search NASA⌕ Search

SEARCH · Search NASA

Results for “contingency control”

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 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS2001

Inviscid Flow Computations of the Shuttle Orbiter for Mach 10 and 15 and Angle of Attack 40 to 60 Degrees

This report documents the results of a computational study done to compute the inviscid longitudinal aerodynamic characteristics of the Space Shuttle Orbiter for Mach numbers 10 and 15 at angles of attack of 40, 50, 55, and 60 degrees. These computations were done to provide limited aerodynamic data in support of the Orbiter contingency abort task. The Orbiter had all the control surfaces in the undeflected position. The unstructured grid software FELISA was used for these computations with the equilibrium air option. Normal and axial force coefficients and pitching moment coefficients were computed. The hinge moment coefficients of the body flap and the inboard and outboard elevons were also computed. These results were compared with Orbiter Air Data Book (OADB) data and those computed using GASP. The comparison with the GASP results showed very good agreement in Cm and Ca at all the points. The computed axial force coefficients were smaller than those computed by GASP. There were noticeable differences between the present results and those in the OADB at angles of attack greater than 50 degrees.

Prabhu, Ramadas K.↗
NASA NTRS2010

Contingency Operations of Americas Next Moon Rocket, Ares V

America has begun the development of a new space vehicle system which will enable humans to return to the moon and reach even farther destinations. The system is called Constellation: it has 2 earth-launch vehicles, Ares I and Ares V; a crew module, Orion; and a lander, Altair with descent and ascent stages. Ares V will launch an Earth Departure Stage (EDS) and Altair into low earth orbit. Ares I will launch the Orion crew module into low earth orbit where it will rendezvous and dock with the Altair and EDS "stack". After rendezvous, the stack will contain four complete rocket systems, each capable of independent operations. Of course this multiplicity of vehicles provides a multiplicity of opportunities for off-nominal behavior and multiple mitigation options for each. Contingency operations are complicated by the issues of crew safety and the possibility of debris from the very large components impacting the ground. This paper examines contingency operations of the EDS in low earth orbit, during the boost to translunar orbit, and after the translunar boost. Contingency operations under these conditions have not been a consideration since the Apollo era and analysis of the possible contingencies and mitigations will take some time to evolve. Since the vehicle has not been designed, much less built, it is not possible to evaluate contingencies from a root-cause basis or from a probability basis; rather they are discussed at an effects level (such as the reaction control system is consuming propellant at a high rate). Mitigations for the contingencies are based on the severity of the off-nominal condition, the time of occurrence, recovery options, options for alternate missions, crew safety, evaluation of the condition (forensics) and future prevention. Some proposed mitigations reflect innovation in thinking and make use of the multiplicity of on-orbit resources including the crew; example: Orion could do a "fly around" to allow the crew to determine the condition and cause of a partially separated payload shroud. Other mitigations are really alternate missions; example, an engine out on during ascent resulted in insufficient propellant for the lunar mission, but the on-orbit vehicle stack is otherwise perfect and can pursue an alternate mission, such as a high ballistic trajectory to test the high-speed atmospheric reentry of Orion. Evaluation and presentation of contingency operations at this early stage of the development of the Ares V rocket will improve the design of the vehicle and lay the groundwork for the exhaustive contingency planning which must be done after the vehicle is built as preparations for operations.

Jaap, John↗
NASA NTRS2011

Solar Dynamics Observatory Guidance, Navigation, and Control System Overview

The Solar Dynamics Observatory (SDO) was designed and built at the Goddard Space Flight Center, launched from Cape Canaveral on February 11, 2010, and reached its final geosynchronous science orbit on March 16, 2010. The purpose of SDO is to observe the Sun and continuously relay data to a dedicated ground station. SDO remains Sun-pointing throughout most of its mission for the instruments to take measurements of the Sun. The SDO attitude control system (ACS) is a single-fault tolerant design. Its fully redundant attitude sensor complement includes sixteen coarse Sun sensors (CSSs), a digital Sun sensor (DSS), three two-axis inertial reference units (IRUs), and two star trackers (STs). The ACS also makes use of the four guide telescopes included as a part of one of the science instruments. Attitude actuation is performed using four reaction wheels assemblies (RWAs) and eight thrusters, with a single main engine used to provide velocity-change thrust for orbit raising. The attitude control software has five nominal control modes, three wheel-based modes and two thruster-based modes. A wheel-based Safehold running in the attitude control electronics box improves the robustness of the system as a whole. All six modes are designed on the same basic proportional-integral-derivative attitude error structure, with more robust modes setting their integral gains to zero. This paper details the final overall design of the SDO guidance, navigation, and control (GN&C) system and how it was used in practice during SDO launch, commissioning, and nominal operations. This overview will include the ACS control modes, attitude determination and sensor calibration, the high gain antenna (HGA) calibration, and jitter mitigation operation. The Solar Dynamics Observatory mission is part of the NASA Living With a Star program, which seeks to understand the changing Sun and its effects on the Solar System, life, and society. To this end, the SDO spacecraft carries three Sun-observing instruments: Helioseismic and Magnetic Imager (HMI), led by Stanford University; Atmospheric Imaging Assembly (AIA), led by Lockheed Martin Space and Astrophysics Laboratory; and Extreme Ultraviolet Variability Experiment (EVE), led by the University of Colorado. The basic mission is to observe the Sun for a very high percentage of the 5-year mission (10-year goal) with long stretches of uninterrupted observations and with constant, high-data-rate transmission to a dedicated ground station to be located in White Sands, New Mexico. These goals guided the design of the spacecraft bus that will carry and service the three-instrument payload. Overarching design goals for the bus are geosynchronous orbit, near-constant Sun observations with the ability to fly through eclipses, and constant HGA contact with the dedicated ground station. A three-axis stabilized ACS is needed both to point at the Sun accurately and to keep the roll about the Sun vector correctly positioned with respect to the solar north pole. This roll control is especially important for the magnetic field imaging of HM I. The mission requirements have several general impacts on the ACS design. Both the AIA and HMI instruments are very sensitive to the blurring caused by jitter. Each has an image stabilization system (ISS) with some ability to filter out high frequency motion, but below the bandwidth of the ISS the control system must compensate for disturbances within the ACS bandwidth or avoid exciting jitter at higher frequencies. Within the ACS bandwidth, the control requirement imposed by AIA is to place the center of the solar disk no more than 2 arc sec, 3 , from a body-defined target based on one of the GTs that accompany the instrument. This body-defined target, called the science reference boresight (SRB), was determined from the postlaunch orientation of the GTs by averaging the bounding telescope boresights for pitch to get a pitch SRB coordinate, and by averaging the bounding boresights for yaw toet the yaw SRB coordinate. The location of this SRB in the 0.5-deg field-of-view for each GT then becomes the central target for each telescope; one GT is selected for use as the ACS controlling guide telescope (CGT) at any given time. Fine Sun-pointing is effected based on this SRB for all three instruments when the Sun is within the linear range of the CGT. In addition to limiting jitter, HMI science requires averaging several observations, making the instrument sensitive to low frequency motion that induces differential motion between each observation. This requires the spacecraft attitude to be stable about the roll axis to approximately 10 arcsec over a ten-minute period. Instrument calibrations require that the spacecraft point the SRB up to 2.5 degrees in pitch and yaw away from the center of the Sun, placing the Sun outside the field-of-view of the guide telescopes. In such instances, when the GTs cannot provide the definitive target for the ACS, on-board attitude determination combined with ephemeris prediction of the Sun direction must provide the definitive target. EVE is capable of observing the Sun with less dependence on attitude control. However, the ground data processing needs for calibrations result in the most strict attitude knowledge requirements for the mission: [35,70,70] arcsec, 3 , of knowledge with respect to the center of the solar disk. In addition to driving the ACS sensor selection, the knowledge requirements, which have their effect primarily during Inertial mode calibrations, drive the accuracy requirements for the solar ephemeris. The need to achieve and maintain geosynchronous orbit (GEO) drove the need for high-efficiency propulsive systems and appropriate attitude control. The main engine provided high specific impulse for the maneuvers to attain GEO, while the smaller ACS thrusters managed the disturbance torques of the larger engine and provided the capability for much smaller adjustment burns on orbit. SDO s large solar profile means that solar radiation pressure is a large torque disturbance, and the momentum buildup from this disturbance and the GEO altitude drives the ACS to use thrusters to manage vehicle momentum. The demanding data capture budget for the mission, however, requires SDO to avoid frequent thruster maneuvers, while concerns about on-orbit jitter restrict the maximum desired wheel speeds desired from the RWAs. The plan for on-orbit wheel speed and momentum management will be discussed as well as what is now being done in operation after the jitter environment was characterized. The SDO ACS hardware complement is single-fault tolerant. Two main processors carry virtually identical copies of the command and data handling and ACS software, and two identical attitude control electronics (ACE) boxes carry Coldfire processors with contingency ACS software and other hardware interface cards; the ACE structure allows reaction wheels to be commanded by the Sun-pointing Safehold independent of the Mil Std 1553 data bus. The sixteen Adcole CSSs are grouped into primary and backup sets of eight sensors, each set providing the ability to calculate a sun vector. Each set of eight eyes provides full 4 -steradian coverage. The Adcole DSS comprises an optics head and a separate electronics box providing a 1553 data interface. The electronics box is mounted inside the Faraday cage created by the spacecraft bus module. The DSS head with its 32- deg square FOV is mounted on the instrument module with its boresight along the spacecraft X axis, nearly aligned with the Sun during observations. Adcole has designed the DSS calibration parameters so that the accuracy is 0.24 arcminutes within 10 deg of the boresight, and diminishes to 3 arcminutes as the Sun moves towards the edges of its FOV . This DSS calibration scheme provides higher accuracy attitude determination over the range of the instrument calibration maneuvers.

Morgenstern, Wendy M.↗
NASA NTRS2006

AERCam Autonomy: Intelligent Software Architecture for Robotic Free Flying Nanosatellite Inspection Vehicles

The NASA Johnson Space Center has developed a nanosatellite-class Free Flyer intended for future external inspection and remote viewing of human spacecraft. The Miniature Autonomous Extravehicular Robotic Camera (Mini AERCam) technology demonstration unit has been integrated into the approximate form and function of a flight system. The spherical Mini AERCam Free Flyer is 7.5 inches in diameter and weighs approximately 10 pounds, yet it incorporates significant additional capabilities compared to the 35-pound, 14-inch diameter AERCam Sprint that flew as a Shuttle flight experiment in 1997. Mini AERCam hosts a full suite of miniaturized avionics, instrumentation, communications, navigation, power, propulsion, and imaging subsystems, including digital video cameras and a high resolution still image camera. The vehicle is designed for either remotely piloted operations or supervised autonomous operations, including automatic stationkeeping, point-to-point maneuvering, and waypoint tracking. The Mini AERCam Free Flyer is accompanied by a sophisticated control station for command and control, as well as a docking system for automated deployment, docking, and recharge at a parent spacecraft. Free Flyer functional testing has been conducted successfully on both an airbearing table and in a six-degree-of-freedom closed-loop orbital simulation with avionics hardware in the loop. Mini AERCam aims to provide beneficial on-orbit views that cannot be obtained from fixed cameras, cameras on robotic manipulators, or cameras carried by crewmembers during extravehicular activities (EVA s). On Shuttle or International Space Station (ISS), for example, Mini AERCam could support external robotic operations by supplying orthogonal views to the intravehicular activity (IVA) robotic operator, supply views of EVA operations to IVA and/or ground crews monitoring the EVA, and carry out independent visual inspections of areas of interest around the spacecraft. To enable these future benefits with minimal impact on IVA operators and ground controllers, the Mini AERCam system architecture incorporates intelligent systems attributes that support various autonomous capabilities. 1) A robust command sequencer enables task-level command scripting. Command scripting is employed for operations such as automatic inspection scans over a region of interest, and operator-hands-off automated docking. 2) A system manager built on the same expert-system software as the command sequencer provides detection and smart-response capability for potential system-level anomalies, like loss of communications between the Free Flyer and control station. 3) An AERCam dynamics manager provides nominal and off-nominal management of guidance, navigation, and control (GN&C) functions. It is employed for safe trajectory monitoring, contingency maneuvering, and related roles. This paper will describe these architectural components of Mini AERCam autonomy, as well as the interaction of these elements with a human operator during supervised autonomous control.

Fredrickson, Steven E.↗
NASA NTRS1990

Shuttle rendezvous and proximity operations

Shuttle rendezvous and proximity operations trajectory control techniques are reviewed and it is noted that they have been affected by many factors including Shuttle system design constraints such as limited forward RCS and single point radar failures. Crew training requirements and mission operations constraints such as large launch windows, flexibility, and contingency profile interrupts are also integral factors. The resulting trajectory control design primarily uses ground support for the launch and orbit adjust phases, standardized crew techniques utilizing onboard software for the relative navigation flight phase, and mission unique manual control for a flexible proximity operations phase.

Pearson, Don J.↗
NASA NTRS2000

Modeling the Fault Tolerant Capability of a Flight Control System: An Exercise in SCR Specification

In life-critical and mission-critical applications, it is important to make provisions for a wide range of contingencies, by providing means for fault tolerance. In this paper, we discuss the specification of a flight control system that is fault tolerant with respect to sensor faults. Redundancy is provided by analytical relations that hold between sensor readings; depending on the conditions, this redundancy can be used to detect, identify and accommodate sensor faults.

Alexander, Chris↗
NASA NTRS2005

Introduction and Mission Response Team (MRT)

On February 1, 2003 the Space Shuttle Columbia, returning to Earth with a crew of seven astronauts, disintegrated along a track extending from California to Louisiana. Observers on the ground filmed breakup of the spacecraft. Debris fell along a 567 statute mile track from Littlefield, Texas to Fort Polk, Louisiana; the largest ever recorded debris field. At the time of the accident the National Aeronautics and Space Administration (NASA) flight surgeon on-duty at the Mission Control Center (MCC) in Houston, Texas initiated the medical contingency response. The DOD surgeon at Patrick Air Force Base was notified, NASA medical personnel were recalled and the services of Armed Forces Institute of Pathology (AFIP) were requested. Subsequent to the accident the NASA flight surgeons that had supported the crew on orbit now provided medical support to the crewmember s families. Federal Emergency Management Agency (FEMA), the National Transportation Safety Board (NTSB), the Federal Bureau of Investigation (FBI) and numerous other federal, state and local agencies along with the citizens of Texas and Louisiana responded to the disaster. Search and recovery was managed from a Disaster Field Office (DFO) established in Lufkin, Texas. Mishap Investigation Team (MIT) medical operations were managed from Barksdale Air Force Base, Louisiana. Accident investigation teams (Columbia Accident Investigation Task Force (CAITF) and Columbia Accident Investigation Board (CAIB)) appointed immediately after the disaster included current and former authorities in space medicine. In August 2003, the CAIB concluded its investigation and released its findings in a report published in February 2004.

Pool, Sam↗
NASA NTRS1993

Computerized atmospheric trace contaminant control simulation for manned spacecraft

Buildup of atmospheric trace contaminants in enclosed volumes such as a spacecraft may lead to potentially serious health problems for the crew members. For this reason, active control methods must be implemented to minimize the concentration of atmospheric contaminants to levels that are considered safe for prolonged, continuous exposure. Designing hardware to accomplish this has traditionally required extensive testing to characterize and select appropriate control technologies. Data collected since the Apollo project can now be used in a computerized performance simulation to predict the performance and life of contamination control hardware to allow for initial technology screening, performance prediction, and operations and contingency studies to determine the most suitable hardware approach before specific design and testing activities begin. The program, written in FORTRAN 77, provides contaminant removal rate, total mass removed, and per pass efficiency for each control device for discrete time intervals. In addition, projected cabin concentration is provided. Input and output data are manipulated using commercial spreadsheet and data graphing software. These results can then be used in analyzing hardware design parameters such as sizing and flow rate, overall process performance and program economics. Test performance may also be predicted to aid test design.

Perry, J. L.↗
NASA NTRSDate not supplied

A Concept of Operations (ConOps) of an In-time Aviation Safety Management System (IASMS) for Advanced Air Mobility (AAM)

The growth of new emerging operations involving Advanced Air Mobility (AAM) necessitates developing a perspective for an In-time Aviation Safety Management System (IASMS). This perspective advances from the National Academies report on IASMS and its recommendation for developing a Concept of Operations (ConOps) for IASMS. A ConOps has been developed for In-time System-Wide Safety Assurance (ISSA) from which the IASMS ConOps pivots to provide a robust scope commensurate with the broad vision defined by the National Academies. The IASMS ConOps focuses on emerging operations and spans innovations in Unmanned Aircraft System (UAS) and an increasingly complex ecosystem comprised of a widening mix of vehicles and technologies, Urban Air Mobility (UAM) with industry-federated services, traditional operations, as well as new supersonic aircraft and space launch systems.The challenge for the IASMS ConOps is to be broad to encompass innovations in the coming years and decades while agile to ensure levels of safety compatible with operational and certification requirements of the National Airspace System (NAS). The IASMS ConOps interweaves increasing complexity of operational safety capabilities and unlocking UAS Maturity Levels (UMLs). The relationships between increased complexity of automation and automated systems, fewer operators who are not as traditionally higher skilled, more complex operational environments, and aviation operations management with mixed aircraft and equipage pose a multi-dimensional space for IASMS capabilities essential for safety assurance and risk management. Instantiating IASMS capabilities and how they would be integral to AAM operations and increasing maturity of UAM could be accomplished through a series of Safety Demonstrators. These Safety Demonstrators could provide increased understanding and insight into use of controls for risk mitigation, means of compliance for certification, and operational experience with safety services such as in relation to contingency management. The IASMS capabilities can be viewed as initially residing with the vehicle, airspace, and Supplemental Data Service Provider (SDSP). For example, vehicle capabilities include communications including the command and control link, Remote Identification (ID), conflict advisory/alerting, and UAS system monitoring. These capabilities monitor and assess data such as battery health, aircraft state, and human performance. Complexity of ISAMS capabilities depends on a number of factors. These factors are intendedonly as a notional categorization with the purpose being to reflect the complexity of the AAM ecosystem that would drive up the complexity of ISSA capabilities including systems, sensors, models, standards, and controls. Factors could include the Vehicle Flight Management, Environment, Airspace, and Contingency Management. Each of these factors can be comprised of multiple sub-factors that contribute to increasing complexity. For example, Airspace at a lower level of complexity could be dedicated to UTM operations that are unmonitored, and at a higher level of complexity could involve mixed UTM and ATM operations. The IASMS concept includes safety services that provide data and information to different participants in AAM. The roles and responsibilities of participants can be defined using the Responsible-Accountable-Consulted-Informed (RACI) analysis. For example, for the safety service involving the Remote ID, the Operator would be accountable for providing the data, the Vehicle would be responsible for transmitting it, and the USS, SDSP, Vertiports, FIMS (FAA), and Public Entities such as safety services would be informed by receiving the data. The IASMS ConOps identifies the capabilities needed for risk mitigation and safety assurance in the increasingly complex national airspace. The ConOps serves as a pathway for engaging with industry to gain operational experience including through the Safety Demonstrator series, the RACI analysis, and operational complexity factors. The ConOps serves to integrate these different perspectives to build a cohesive and cogent approach to an AAM safety management system.

In-Time Aviation Safety Management System↗
NASA NTRS2007

Overview of Umbilical Extravehicular Activity (EVA) Interfaces in Life Support Systems on Spacecraft Vehicles and Applications for the Crew Exploration Vehicle (CEV)

Extravehicular Activities (EVAs) for manned spacecraft vehicles have been performed for contingencies and nominal operations numerous times throughout history. This paper will investigate how previous U.S. manned spacecraft vehicles provided life support to crewmembers performing the EVA. Specifically defined are umbilical interfaces with respect to crewmember cooling, drinking water, air (or oxygen), humidity control, and carbon dioxide removal. As historical data is available, the need for planned versus contingency EVAs in previous vehicles as well as details for a nominal EVA day versus a contingency EVA day will be discussed. The hardware used to provide the cooling, drinking water, air (or oxygen), humidity control, and carbon dioxide removal, and the general functions of that hardware, will also be detailed, as information is available. The Crew Exploration Vehicle (CEV or Orion) EVA interfaces will be generically discussed to provide a glimpse of how similar they are to the EVA interfaces in previous vehicles. Conclusions on strategies that should be used for CEV based on previous spacecraft EVA interfaces will be made in the form of questions and recommendations.

Peterson, Laurie J.↗
NASA NTRSDate not supplied

Short Circuiting the Controller – Missteps in Maintenance and Inspection of Process and Wiring in STS-93

The primary objective of the Space Transportation System mission 93 (STS-93) was to deploy the Chandra X-Ray Observatory. Chandra, the world's most powerful X-Ray telescope, allowed scientists from around the world to study some of the most distant and dynamic objects in the universe. Stripped of nearly 7,000 pounds of its own gear to make room for the payload, the orbiter assigned to this mission was Space Shuttle Columbia. Prior to STS-93, Columbia had flown 25 flights and was NASA's oldest and heaviest orbiter. On July 23, 1999, after two prior launch scrubs, Eileen Collins and her crew of four launched from Kennedy Space Center. About five seconds after launch, Mission Control at Johnson Space Center detected a voltage drop on one of Columbia's electrical buses. As a result of this power fluctuation, a primary and back-up Main Engine controller dropped offline. Given design redundancy, the two remaining controllers supported all three engines. If there had been any other AC bus issues, one engine of the three on the Orbiter would have shut down. The redundant set of digital computer units in each engine controller saved Columbia and her crew from a very risky contingency abort. Post-flight inspection revealed soot on a screw head and a hole in an adjacent Kapton insulated wire. The single strand of polyimide wire was located nearly half-way down the payload bay. The Shuttle Independent Assessment Team (SIAT) reported that the wire had rubbed and chaffed against a burred screw head. The burr was later determined to be the result of overtightening of the screw by a technician during a maintenance refurbishment. Alone, the burr may not have been problematic, but later, during another ground processing event, possibly years after, someone inadvertently stepped on the wiring harness. With the pressure and motion of unintended contact, some of the Kapton insulation rubbed off against the burred screw head. The SIAT suspected the wire damage was pre-existing and was caused 4 or 5 years prior to the flight. Finally, the intense vibrations during the launch sequence allowed contact between the exposed conductor and exposed metal area on the burred screw head, resulting in the arcing and shorting of the wire. Due to the quick turnaround times of Space Shuttle Orbiters, wiring issues caused from multiple maintenance events were often overlooked. Additionally, failing to incorporate thorough and early inclusion of human systems integration (HSI) applications as a crucial part of the decision process can result in these types of misshaps. In order to reduce human error associated with integrated manufacturing, maintenance, refurbishment and flight preparations, wire inspection criteria should be refined and standardized, visual inspection processes should be quantified, and technicians should be certified by specially trained instructors. This case, among many others, unveils why human error management and development of safety metrics is a vital piece in the development of complex systems, and why it should be supported aggressively and implemented program wide.

Human Systems Integration↗
NASA NTRS2025

Time Course of Effects of Carbon Dioxide Exposure on Physical and Cognitive Performance in a Simulated Surface Extravehicular Activity Contingency Scenario

INTRODUCTION Carbon dioxide (CO 2 ) is a metabolic byproduct produced by humans that must be scrubbed from the atmosphere by environmental control and life support systems in space vehicles and spacesuits to prevent buildup. Current nominal CO 2 limits are set by NASA Standard 3001, however, limits during contingency situations are not specified. The purpose of this study was to characterize and quantify the physiological, cognitive, and self-assessed symptom and performance metrics as a function of inspired CO 2 (P I CO 2 ) during a simulated 1-hour contingency lunar EVA scenario in virtual reality (VR). METHODS Fifteen healthy subjects completed 7 simulated EVA scenarios walking on a passive treadmill for one hour breathing dry, ambient air mixed with added CO 2 in a blind, counterbalanced manner (P I CO 2 : 0, 5, 10, 15, 20, 25, 30 mmHg) simulating a 2.0 km contingency EVA walkback to a habitat on the lunar surface in the event of a CO 2 scrubber malfunction. Subjects were immersed in a Lunar VR environment and asked to maintain their walking speed between 2.1 km/h and an upper limit individually calibrated to a fixed metabolic workload of 1.3 L/min of O 2 consumption, and performed periodic cognitive tasks and continuous cardiopulmonary measurements. Self-assessments of symptoms and task performance were measured via verbal Likert-scale survey at the onset of the walkback and at 10-minute intervals thereafter. RESULTS The time course of cardiopulmonary, cognitive, and self-reported responses at each level of P I CO 2 will be presented. All 15 subjects were able to complete the 1-hr walk back task at all CO 2 levels. Physiological responses were rapid, typically within 1 to 5 minutes. No effects of time were detected for cognitive measures. Symptomatic ratings of headache, shortness of breath, and fatigue demonstrated a time-course development, reaching asymptote after 40 minutes of CO 2 exposure. DISCUSSION These findings will inform the posture of risk associated with CO 2 exposure on human health and performance during microgravity and planetary surface operations, This will help inform decisions related to space suit and environmental life support hardware requirements and EVA operational limits for contingency extravehicular activity (EVA) scenarios.

carbon dioxide↗
NASA NTRS1980

Thermodynamic performance testing of the orbiter flash evaporator system

System level testing of the space shuttle orbiter's development flash evaporator system (FES) was performed in a thermal vacuum chamber capable of simulating ambient ascent, orbital, and entry temperature and pressure profiles. The test article included the evaporator assembly, high load and topping exhaust duct and nozzle assemblies, and feedwater supply assembly. Steady state and transient heat load, water pressure/temperature and ambient pressure/temperature profiles were imposed by especially designed supporting test hardware. Testing in 1978 verified evaporator and duct heater thermal design, determined FES performance boundaries, and assessed topping evaporator plume characteristics. Testing in 1979 combined the FES with the other systems in the orbiter active thermal control subsystem (ATCS). The FES met or exceeded all nominal and contingency performance requirements during operation with the integrated ATCS. During both tests stability problems were encountered during steady state operations which resulted in subsequent design changes to the water spray nozzle and valve plate assemblies.

Jaax, J. R.↗
NASA NTRS2005

Opportunities for Launch Site Integrated System Health Engineering and Management

The launch site processing flow involves operations such as functional verification, preflight servicing and launch. These operations often include hazards that must be controlled to protect human life and critical space hardware assets. Existing command and control capabilities are limited to simple limit checking durig automated monitoring. Contingency actions are highly dependent on human recognition, decision making, and execution. Many opportunities for Integrated System Health Engineering and Management (ISHEM) exist throughout the processing flow. This paper will present the current human-centered approach to health management as performed today for the shuttle and space station programs. In addition, it will address some of the more critical ISHEM needs, and provide recommendations for future implementation of ISHEM at the launch site.

Waterman, Robert D.↗
NASA NTRS2006

Notional Airspace Operations Demonstration Plan

The airspace operations demonstration (AOD) is intended to show that the Access 5 Step 1 functional requirements can be met. The demonstration will occur in two phases. The initial on-range phase will be carried out in restricted airspace to demonstrate the cooperative collision avoidance (CCA) functional requirements and to provide risk-reduction for the AOD by allowing the test team to rehearse some elements of the demonstration mission. The CCA system to be used in these flights is based on Automatic Dependent Surveillance-Broadcast (ADS-B) which is a commercially-available system by which airplanes constantly broadcast their current position and altitude to other aircraft and ground resources over a dedicated radio datalink. The final phase will occur in the national airspace (NAS) and will be the formal demonstration of the remainder of the proposed functional requirements. The general objectives of the AOD are as follows: (1) Demonstrate that the UAS can aviate in the NAS (2) Demonstrate that the UAS can navigate in the NAS (3) Demonstrate that the UAS can communicate with the NAS (4) Demonstrate that the UAS can perform selected collision avoidance functions in the NAS (5) Demonstrate that the UAS can evaluate and avoid weather conflicts in the NAS (6) Demonstrate that the UAS can provide adequate command and control in the NAS In addition to the stated objectives, there are a number of goals for the flight demonstration. The demo can be accomplished successfully without achieving these goals, but these goals are to be used as a guideline for preparing for the mission. The goals are: (1) Mission duration of at least 24 hours (2) Loiter over heavy traffic to evaluate the data block issue identified during the Access 5 Airspace Operations Simulations (3) Document the contingency management process and lessons learned (4) Document the coordination process for Ground Control Stations (GCS) handoff (5) Document lessons learned regarding the process of flying in the NAS Preliminary planning for a notional mission to achieve the objectives and goals has been prepared. The planning is intended to serve as a guide for detailed planning of the AOD.

Trongale, Nicholas A.↗
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↗