Search NASA⌕ Search

SEARCH · Search NASA

Results for “support”

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 451 records · Page 25

Don/Doff support stand for use with rear entry space suits

A don/doff support stand for use with rear entry space suits is disclosed. The support stand is designed for use in one-g environments; however, certain features of the stand can be used on future space-craft, lunar or planetary bases. The present invention has a retainer which receives a protruding lug fixed on the torso section of the space suit. When the lug is locked in the retainer, the space suit is held in a generally upright position. In a one-g environment a portable ladder is positioned adjacent to the rear entry of the space suit supported by the stand. The astronaut climbs up the ladder and grasps a hand bar assembly positioned above the rear entry. The astronaut then slips his legs through the open rear entry and down into the abdominal portion of the suit. The astronaut then lowers himself fully into the suit. The portable ladder is then removed and the astronaut can close the rear entry door. The lug is then disengaged from the retainer and the astronaut is free to engage in training exercises in the suit. When suit use is over, the astronaut returns to the stand and inserts the lug into the retainer. A technician repositions the ladder. The astronaut opens the rear entry door, grasps the hand bar assembly and does a chin-up to extricate himself from the suit. The astronaut climbs down the movable ladder while the suit is supported by the stand.

Kosmo, Joseph J.↗

In-situ Resource Utilization (ISRU) to Support the Lunar Outpost and the Rationale for Precursor Missions

One of the ways that the Constellation Program can differ from Apollo is to employ a live-off-the-land or In-Situ Resource Utilization (ISRU) supported architecture. The options considered over the past decades for using indigenous materials have varied considerably in terms of what resources to attempt to acquire, how much to acquire, and what the motivations are to acquiring these resources. The latest NASA concepts for supporting the lunar outpost have considered many of these plans and compared these options to customers requirements and desires. Depending on the architecture employed, ISRU technologies can make a significant contribution towards a sustainable and affordable lunar outpost. While extensive ground testing will reduce some mission risk, one or more flight demonstrations prior to the first crew's arrival will build confidence and increase the chance that outpost architects will include ISRU as part of the early outpost architecture. This presentation includes some of the options for using ISRU that are under consideration for the lunar outpost, the precursor missions that would support these applications, and a notional timeline to allow the lessons learned from the precursor missions to support outpost hardware designs.

Simon, Thomas M.↗

Contingency Support Simulation for the Tracking and Data Relay Satellite System (TDRSS)

In March 2006, the Tracking and Data Relay Satellite (TDRS)-3 experienced an unexpected thrusting event, which caused significant changes to its orbit. Recovery from this anomaly was protracted, raising concerns during the Independent Review Team (IRT) investigation of the anomaly regarding the contingency response readiness. The simulations and readiness exercises discussed in this paper were part of the response to the IRT concerns. This paper explains the various levels of simulation needed to enhance the proficiency of the Flight Dynamics Facility (FDF) and supporting elements in recovery from a TDRS contingency situation. The main emergency to address is when a TDRS has experienced uncommanded, unreported, or misreported thrusting, causing a ground station to lose the ability to acquire the spacecraft, as happened in 2006. The following levels of simulation are proposed: 1) Tests that would be performed by the individual support sites to verify that internal procedures and tools are in place and up to date; 2) Tabletop simulations that would involve all of the key support sites talking through their respective operating procedures to ensure that proper notifications are made and communications links are established; and 3) Comprehensive simulations that would be infrequent, but realistic, involving data exchanges between ground sites and voice and electronic communications among the supporting elements.

Dykes, Andy↗

Summary of NASA Support of the F-111 Development Program: December 1962 - December 1965 - Part 1

The F-111 is a biservice, multimission, tactical aircraft being developed for the Air Force and Navy by General Dynamics and Grumman. The general arrangement of the F-111 is shown in figure 1. This aircraft, through the use of the "variable sweep wing" concept, offers the possibility of combining a wide range of mission capabilities into a single aircraft. The F-111 is a direct outgrowth of the Langley Research Center's variable sweep research which began in 1947. The early research culminated in the X-5 variable sweep research airplane which demonstrated the advantage and feasibility of in-flight sweep variation~ The X-5 utilized the translating wing concept to offset the longitudinal stability variation with sweep changes. Later Langley research beginning in 1958 resulted in the "outboard pivot" concept which eliminated the need for wing translation and led .to the TFX (F-111) concept. A chronology of the NACA/NASA variable sweep research effort and direct su~port of the TFX up to the awarding of the contract to General Dynamics/Grumman on November 24, 1962, is presented in refer'ence 1. Since the awarding of the contract, the Langley, Ames, Lewis, and Flight Research Centers have been actively supporting the F-111 development program. Because of the strong NASA interest in this aircraft and the large magnitude of NASA support involved, it was felt desirable to document this support. The purpose of this paper therefore is to present a brief summary of the NASA support, in chronological order, through December 1965, beginning with the awarding of the contract in November 1962.

Source record↗

An EXPRESS Rack Overview and Support for Microgravity Research on the International Space Station (ISS)

The EXpedite the PRocessing of Experiments to Space Station or EXPRESS Rack System has provided accommodations and facilitated operations for microgravity-based research payloads for over 6 years on the International Space Station (ISS). The EXPRESS Rack accepts Space Shuttle middeck type lockers and International Subrack Interface Standard (ISIS) drawers, providing a modular-type interface on the ISS. The EXPRESS Rack provides 28Vdc power, Ethernet and RS-422 data interfaces, thermal conditioning, vacuum exhaust, and Nitrogen supply for payload use. The EXPRESS Rack system also includes payload checkout capability with a flight rack or flight rack emulator prior to launch, providing a high degree of confidence in successful operations once an-orbit. In addition, EXPRESS trainer racks are provided to support crew training of both rack systems and subrack operations. Standard hardware and software interfaces provided by the EXPRESS Rack simplify the integration processes for ISS payload development. The EXPRESS Rack is designed to accommodate multidiscipline research, allowing for the independent operation of each subrack payload within a single rack. On-orbit operations began for the EXPRESS Rack Project on April 24, 2001, with one rack operating continuously to support high-priority payloads. The other on-orbit EXPRESS Racks operate based on payload need and resource availability. Over 50 multi-discipline payloads have now been supported on-orbit by the EXPRESS Rack Program. Sustaining engineering, logistics, and maintenance functions are in place to maintain hardware, operations and provide software upgrades. Additional EXPRESS Racks are planned for launch prior to ISS completion in support of long-term operations and the planned transition of the U.S. Segment to a National Laboratory.

Pelfrey, Joseph J.↗

Tools to Support Human Factors and Systems Engineering Interactions During Early Analysis

We describe an approach and existing software tool support for effective interactions between human factors engineers and systems engineers in early analysis activities during system acquisition. We examine the tasks performed during this stage, emphasizing those tasks where system engineers and human engineers interact. The Concept of Operations (ConOps) document is an important product during this phase, and particular attention is paid to its influences on subsequent acquisition activities. Understanding this influence helps ConOps authors describe a complete system concept that guides subsequent acquisition activities. We identify commonly used system engineering and human engineering tools and examine how they can support the specific tasks associated with system definition. We identify possible gaps in the support of these tasks, the largest of which appears to be creating the ConOps document itself. Finally, we outline the goals of our future empirical investigations of tools to support system concept definition.

Thronesbery, Carroll↗

Tools to Support Human Factors and Systems Engineering Interactions During Early Analysis

We describe an approach and existing software tool support for effective interactions between human factors engineers and systems engineers in early analysis activities during system acquisition. We examine the tasks performed during this stage, emphasizing those tasks where system engineers and human engineers interact. The Concept of Operations (ConOps) document is an important product during this phase, and particular attention is paid to its influences on subsequent acquisition activities. Understanding this influence helps ConOps authors describe a complete system concept that guides subsequent acquisition activities. We identify commonly used system engineering and human engineering tools and examine how they can support the specific tasks associated with system definition. We identify possible gaps in the support of these tasks, the largest of which appears to be creating the ConOps document itself. Finally, we outline the goals of our future empirical investigations of tools to support system concept definition.

Thronesbery, Carroll↗

CCMC Plans to Support SDO Operations

The CCMC will actively support the SDO Mission. It will do this, wherever feasible, by installing and running those models which the SDO science planners deem both appropriate and necessary to enable the science goals of SDO. In this presentation I will outline our philosophy in offering this support, the models we are actively pursuing to enable this, and the modes in which we intend to run these models. I will discuss how users of SDO data will be able to request model runs and analyse their outputs. I will also describe the facilities which we have at our disposal to support this effort, and our expectations for the resource requirements which this support will need.

MacNeice, Peter↗

Proven and Robust Ground Support Systems - GSFC Success and Lessons Learned

Over the past fifteen years, Goddard Space Flight Center has developed several successful science missions in-house: the Wilkinson Microwave Anisotropy Probe (WMAP), the Imager for Magnetopause-to-Aurora Global Exploration (IMAGE), the Earth Observing 1 (EO-1) [1], and the Space Technology 5 (ST-5)[2] missions, several Small Explorers, and several balloon missions. Currently in development are the Solar Dynamics Observatory (SDO) [3] and the Lunar Reconnaissance Orbiter (LRO)[4]. What is not well known is that these missions have been supported during spacecraft and/or instrument integration and test, flight software development, and mission operations by two in house satellite Telemetry and Command (T & C) Systems, the Integrated Test and Operations System (ITOS) and the Advanced Spacecraft Integration and System Test (ASIST). The advantages of an in-house satellite Telemetry and Command system are primarily in the flexibility of management and maintenance - the developers are considered a part of the mission team, get involved early in the development process of the spacecraft and mission operations-control center, and provide on-site, on-call support that goes beyond Help Desk and simple software fixes. On the other hand, care must be taken to ensure that the system remains generic enough for cost effective re-use from one mission to the next. The software is designed such that many features are user-configurable. Where user-configurable options were impractical, features were designed so as to be easy for the development team to modify. Adding support for a new ground message header, for example, is a one-day effort because of the software framework on which that code rests. This paper will discuss the many features of the Goddard satellite Telemetry and Command systems that have contributed to the success of the missions listed above. These features include flexible user interfaces, distributed parallel commanding and telemetry decommutation, a procedure language, the interfaces and tools needed for a high degree of automation, and instantly accessible archives of spacecraft telemetry. It will discuss some of the problems overcome during development, including secure commanding over networks or the Internet, constellation support for the three satellites that comprise the ST-5 mission, and geographically distributed telemetry end users.

Pfarr, Barbara↗

Wireless Avionics Packet to Support Fault Tolerance for Flight Applications

In this protocol and packet format, data traffic is monitored by all network interfaces to determine the health of transmitter and subsystems. When failures are detected, the network inter face applies its recover y policies to provide continued service despite the presence of faults. The protocol, packet format, and inter face are independent of the data link technology used. The current demonstration system supports both commercial off-the-shelf wireless connections and wired Ethernet connections. Other technologies such as 1553 or serial data links can be used for the network backbone. The Wireless Avionics packet is divided into three parts: a header, a data payload, and a checksum. The header has the following components: magic number, version, quality of service, time to live, sending transceiver, function code, payload length, source Application Data Interface (ADI) address, destination ADI address, sending node address, target node address, and a sequence number. The magic number is used to identify WAV packets, and allows the packet format to be updated in the future. The quality of service field allows routing decisions to be made based on this value and can be used to route critical management data over a dedicated channel. The time to live value is used to discard misrouted packets while the source transceiver is updated at each hop. This information is used to monitor the health of each transceiver in the network. To identify the packet type, the function code is used. Besides having a regular data packet, the system supports diagnostic packets for fault detection and isolation. The payload length specifies the number of data bytes in the payload, and this supports variable-length packets in the network. The source ADI is the address of the originating interface. This can be used by the destination application to identify the originating source of the packet where the address consists of a subnet, subsystem class within the subnet, a subsystem unit, and the local ADI number. The destination ADI is used to route the packet to its ultimate destination. At each hop, the sending interface uses the destination address to determine the next node for the data. The sending node is the node address of the interface that is broadcasting the packet. This field is used to determine the health of the subsystem that is sending the packet. In the case of a packet that traverses several intermediate nodes, it may be the node address of the intermediate node. The target node is the node address of the next hop for the packet. It may be an intermediate node, or the final destination for the packet. The sequence number is used to identify duplicate packets. Because each interface has multiple transceivers, the same packet will appear at both receivers. The sequence number allows the interface to correlate the reception and forward a single, unique packet for additional processing. The subnet field allows data traffic to be partitioned into segregated local networks to support large networks while keeping each subnet at a manageable size. This also keeps the routing table small enough so routing can be done by a simple table lookup in an FPGA device. The subsystem class identifies members of a set of redundant subsystems, and, in a hot standby configuration, all members of the subsystem class will receive the data packets. Only the active subsystem will generate data traffic. Specific units in a class of redundant units can be identified and, if the hot standby configuration is not used, packets will be directed to a specific subsystem unit.

Block, Gary L.↗

Performance Testing of Lithium Li-ion Cells and Batteries in Support of JPL's 2003 Mars Exploration Rover Mission

In early 2004, JPL successfully landed two Rovers, named Spirit and Opportunity, on the surface of Mars after traveling > 300 million miles over a 6-7 month period. In order to operate for extended duration on the surface of Mars, both Rovers are equipped with rechargeable Lithium-ion batteries, which were designed to aid in the launch, correct anomalies during cruise, and support surface operations in conjunction with a triple-junction deployable solar arrays. The requirements of the Lithium-ion battery include the ability to provide power at least 90 sols on the surface of Mars, operate over a wide temperature range (-20(super 0)C to +40(super 0)C), withstand long storage periods (e.g., including pre-launch and cruise period), operate in an inverted position, and support high currents (e.g., firing pyro events). In order to determine the inability of meeting these requirements, ground testing was performed on a Rover Battery Assembly Unit RBAU), consisting of two 8-cell 8 Ah lithium-ion batteries connected in parallel. The RBAU upon which the performance testing was performed is nearly identical to the batteries incorporated into the two Rovers currently on Mars. The primary focus of this paper is to communicate the latest results regarding Mars surface operation mission simulation testing, as well as, the corresponding performance capacity loss and impedance characteristics as a function of temperature and life. As will be discussed, the lithium-ion batteries (fabricated by Yardney Technical Products, Inc.) have been demonstrated to far exceed the requirements defined by the mission, being able to support the operation of the rovers for over three years, and are projected to support an even further extended mission.

low temperature electrolytes↗

Modification of the International Space Station USOS to Support Installation and Activation of the Node 3 Element

The International Space Station (ISS) program is nearing an assembly complete configuration with the addition of the final resource node module in early 2010. The Node 3 module will provide critical functionality in support of permanent long duration crews aboard ISS. The new module will permanently house the regenerative Environment Control and Life Support Systems (ECLSS) and will also provide important habitability functions such as waste management and exercise facilities. The ISS program has selected the Port side of the Node 1 "Unity" module as the permanent location for Node 3 which will necessitate architecture changes to provide the required interfaces. The USOS ECLSS fluid and ventilation systems, Internal Thermal Control Systems, and Avionics Systems require significant modifications in order to support Node 3 interfaces at the Node 1 Port location since it was not initially designed for that configuration. This paper outlines the design, development, certification, and implementation of these changes in support of ISS assembly complete.

Link, Dwight E., Jr.↗

Lunar Base Life Support Failures

Dynamic simulation of the lunar outpost habitat life support was undertaken to investigate the impact of life support failures and to investigate responses. Some preparatory static analysis for the Lunar Outpost life support model, an earlier version of the model, and an investigation into the impact of Extravehicular Activity (EVA) were reported previously. (Jones, 2008-01-2184, 2008-01-2017) The earlier model was modified to include possible resupply delays, power failures, recycling system failures, and atmosphere and other material storage failures. Most failures impact the lunar outpost water balance and can be mitigated by reducing water usage. Food solids, nitrogen can be obtained only by resupply from Earth. The most time urgent failure is a lass of carbon dioxide removal capability. Life support failures might be survivable if effective operational solutions are provided in the system design.

Jones, Harry W.↗

Exploration Life Support Critical Questions for Future Human Space Missions

Exploration Life Support (ELS) is a project under NASA s Exploration Technology Development Program. The ELS Project plans, coordinates and implements the development of advanced life support technologies for human exploration missions in space. Recent work has focused on closed loop atmosphere and water systems for a lunar outpost, including habitats and pressurized rovers. But, what are the critical questions facing life support system developers for these and other future human missions? This paper explores those questions and discusses how progress in the development of ELS technologies can help answer them. The ELS Project includes Atmosphere Revitalization Systems (ARS), Water Recovery Systems (WRS), Waste Management Systems (WMS), Habitation Engineering, Systems Integration, Modeling and Analysis (SIMA), and Validation and Testing, which includes the sub-elements Flight Experiments and Integrated Testing. Systems engineering analysis by ELS seeks to optimize the overall mission architecture by considering all the internal and external interfaces of the life support system and the potential for reduction or reuse of commodities. In particular, various sources and sinks of water and oxygen are considered along with the implications on loop closure and the resulting launch mass requirements.

Ewert, Michael K.↗

Lunar Outpost Life Support Architecture Study Based on a High Mobility Exploration Scenario

As scenarios for lunar surface exploration and habitation continue to evolve within NASA s Constellation program, so must studies of optimal life support system architectures and technologies. This paper presents results of a life support architecture study based on a 2009 NASA scenario known as Scenario 12. Scenario 12 represents a consolidation of ideas from earlier NASA scenarios and includes an outpost near the Lunar South Pole comprised of three larger fixed surface elements and four attached pressurized rovers. The scenario places a high emphasis on surface mobility, with planning assuming that all four crewmembers spend roughly 50% of the time away from the outpost on 3-14 day excursions in two of the pressurized rovers. Some of the larger elements can also be mobilized for longer duration excursions. This emphasis on mobility poses a significant challenge for a regenerative life support system in terms of cost-effective waste collection and resource recovery across multiple elements, including rovers with very constrained infrastructure resources. The current study considers pressurized rovers as part of a distributed outpost life support architecture in both stand-alone and integrated configurations. A range of architectures are examined reflecting different levels of closure and distributed functionality. Different lander propellant scavenging options are also considered involving either initial conversion of residual oxygen and hydrogen propellants to water or initial direct oxygen scavenging. Monte Carlo simulations are used to assess the sensitivity of results to volatile high-impact mission variables, including the quantity of residual lander propellants available for scavenging, the fraction of crew time away from the outpost on excursions, total extravehicular activity hours, and habitat leakage. Architectures are evaluated by estimating surpluses or deficits of water and oxygen per 180-day mission and differences in fixed and 10-year-total equivalent system mass (ESM) relative to a reference case. Results are presented based on current assumptions for Scenario 12 and based on Monte Carlo simulations with assumed probability distributions for the high-impact mission variables. The calculated probability of no water or oxygen resupply from Monte Carlo simulations provides a quantitative measure of system robustness that can be used for cost/benefit analyses to identify leading architecture candidates. Areas of technology improvement that are likely to have a significant impact are also suggested.

Lange, Kevin E.↗

Performance Support Tools for Space Medical Operations

The early Constellation space missions are expected to have medical capabilities very similar to those currently on the Space Shuttle and International Space Station (ISS). For Crew Exploration Vehicle (CEV) missions to ISS, medical equipment will be located on ISS, and carried into CEV in the event of an emergency. Flight Surgeons (FS) on the ground in Mission Control will be expected to direct the Crew Medical Officer (CMO) during medical situations. If there is a loss of signal and the crew is unable to communicate with the ground, a CMO would be expected to carry out medical procedures without the aid of a FS. In these situations, performance support tools can be used to reduce errors and time to perform emergency medical tasks. Human factors personnel at Johnson Space Center have recently investigated medical performance support tools for CMOs on-orbit, and FSs on the ground. This area of research involved the feasibility of Just-in-time (JIT) training techniques and concepts for real-time medical procedures. In Phase 1, preliminary feasibility data was gathered for two types of prototype display technologies: a hand-held PDA, and a Head Mounted Display (HMD). The PDA and HMD were compared while performing a simulated medical procedure using ISS flight-like medical equipment. Based on the outcome of Phase 1, including data on user preferences, further testing was completed using the PDA only. Phase 2 explored a wrist-mounted PDA, and compared it to a paper cue card. For each phase, time to complete procedures, errors, and user satisfaction were captured. Information needed by the FS during ISS mission support, especially for an emergency situation (e.g. fire onboard ISS), may be located in many different places around the FS s console. A performance support tool prototype is being developed to address this issue by bringing all of the relevant information together in one place. The tool is designed to include procedures and other information needed by a FS during an emergency, as well as procedures and information to be used after the emergency is resolved. Several walkthroughs of the prototype with FSs have been completed within a mockup of an ISS FS console. Feedback on the current tool design as well as recommendations for existing ISS FS displays were captured.

Byrne, Vicky E.↗

Node 3 Relocation Environmental Control and Life Support System Modification Kit Verification and Updated Status

Node 1 (Unity) flew to International Space Station (ISS) on Flight 2A. Node 1 was the first module of the United States On-Orbit Segment (USOS) launched to ISS. The Node 1 ISS Environmental Control and Life Support (ECLS) design featured limited ECLS capability. The main purpose of Node 1 was to provide internal storage by providing four stowage rack locations within the module and to allow docking of multiple modules and a truss segment to it. The ECLS subsystems inside Node 1 were routed through the element prior to launch to allow for easy integration of the attached future elements, particularly the Habitation Module which was planned to be located at the nadir docking port of Node 1. After Node 1 was on-orbit, the Program decided not to launch the Habitation Module and instead, to replace it with Node 3 (Tranquility). In 2007, the Program became concerned with a potential Russian docking port approach issue for the Russian FGB nadir docking port after Node 3 is attached to Node 1. To solve this concern the Program decided to relocate Node 3 from Node 1 nadir to Node 1 port. To support the movement of Node 3 the Program decided to build a modification kit for Node 1, an on-orbit feedthrough leak test device, and new vestibule jumpers to support the ECLS part of the relocation. This paper provides a design overview of the modification kit, a summary of the Node 1 ECLS re-verification to support the Node 3 relocation from Node 1 nadir to Node 1 port, and a status of the ECLS modification kit installation into Node 1.

Williams, David E.↗

How to Boost Engineering Support Via Web 2.0 - Seeds for the Ares Project...and/or Yours?

The Mission Operations Laboratory (MOL) at Marshall Space Flight Center (MSFC) is responsible for Engineering Support capability for NASA s Ares launch system development. In pursuit of this, MOL is building the Ares Engineering and Operations Network (AEON), a web-based portal intended to provide a seamless interface to support and simplify two critical activities: a) Access and analyze Ares manufacturing, test, and flight performance data, with access to Shuttle data for comparison. b) Provide archive storage for engineering instrumentation data to support engineering design, development, and test. A mix of NASA-written and COTS software provides engineering analysis tools. A by-product of using a data portal to access and display data is access to collaborative tools inherent in a Web 2.0 environment. This paper discusses how Web 2.0 techniques, particularly social media, might be applied to the traditionally conservative and formal engineering support arena. A related paper by the author [1] considers use

Scott, David W.↗