Search NASA⌕ Search

SEARCH · Search NASA

Results for “Supportability”

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
All sourcesNASA NTRSDOE OSTI
NASA NTRS1966

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↗
NASA NTRS2008

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.↗
NASA NTRS2006

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↗
NASA NTRS2005

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↗
NASA NTRS2008

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↗
NASA NTRS2008

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↗
NASA NTRS2009

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.↗
NASA NTRS2007

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↗
NASA NTRS2009

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.↗
NASA NTRS2009

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.↗
NASA NTRS2009

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.↗
NASA NTRS2009

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.↗
NASA NTRS2009

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.↗
NASA NTRS2009

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.↗
NASA NTRS2010

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.↗
NASA NTRS2010

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 I 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 I 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 for Node 1, 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.↗
NASA NTRS2010

Interface Supports Lightweight Subsystem Routing for Flight Applications

A wireless avionics interface exploits the constrained nature of data networks in flight systems to use a lightweight routing method. This simplified routing means that a processor is not required, and the logic can be implemented as an intellectual property (IP) core in a field-programmable gate array (FPGA). The FPGA can be shared with the flight subsystem application. In addition, the router is aware of redundant subsystems, and can be configured to provide hot standby support as part of the interface. This simplifies implementation of flight applications requiring hot stand - by support. When a valid inbound packet is received from the network, the destination node address is inspected to determine whether the packet is to be processed by this node. Each node has routing tables for the next neighbor node to guide the packet to the destination node. If it is to be processed, the final packet destination is inspected to determine whether the packet is to be forwarded to another node, or routed locally. If the packet is local, it is sent to an Applications Data Interface (ADI), which is attached to a local flight application. Under this scheme, an interface can support many applications in a subsystem supporting a high level of subsystem integration. If the packet is to be forwarded to another node, it is sent to the outbound packet router. The outbound packet router receives packets from an ADI or a packet to be forwarded. It then uses a lookup table to determine the next destination for the packet. Upon detecting a remote subsystem failure, the routing table can be updated to autonomously bypass the failed subsystem.

Lux, James P.↗
NASA NTRS2010

Web Design for Space Operations: An Overview of the Challenges and New Technologies Used in Developing and Operating Web-Based Applications in Real-Time Operational Support Onboard the International Space Station, in Astronaut Mission Planning and Mission Control Operations

The International Space Station (ISS) Operations Planning Team, Mission Control Centre and Mission Automation Support Network (MAS) have all evolved over the years to use commercial web-based technologies to create a configurable electronic infrastructure to manage the complex network of real-time planning, crew scheduling, resource and activity management as well as onboard document and procedure management required to co-ordinate ISS assembly, daily operations and mission support. While these Web technologies are classified as non-critical in nature, their use is part of an essential backbone of daily operations on the ISS and allows the crew to operate the ISS as a functioning science laboratory. The rapid evolution of the internet from 1998 (when ISS assembly began) to today, along with the nature of continuous manned operations in space, have presented a unique challenge in terms of software engineering and system development. In addition, the use of a wide array of competing internet technologies (including commercial technologies such as .NET and JAVA ) and the special requirements of having to support this network, both nationally among various control centres for International Partners (IPs), as well as onboard the station itself, have created special challenges for the MCC Web Tools Development Team, software engineers and flight controllers, who implement and maintain this system. This paper presents an overview of some of these operational challenges, and the evolving nature of the solutions and the future use of COTS based rich internet technologies in manned space flight operations. In particular this paper will focus on the use of Microsoft.s .NET API to develop Web-Based Operational tools, the use of XML based service oriented architectures (SOA) that needed to be customized to support Mission operations, the maintenance of a Microsoft IIS web server onboard the ISS, The OpsLan, functional-oriented Web Design with AJAX

Khan, Ahmed↗