SEARCH · Search NASA

Results for “workarounds,”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

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

At least 55 records · Page 3

All sources NASA NTRS DOE OSTI

NASA NTRS2009

Turning Operational Lessons Learned into Design Reality

The capabilities and limitations of a particular system design are well known by the people who operate it. Operational workarounds, operational notes and lessons learned are traditional methods for dealing with and documenting design shortcomings. The beginning of each new program brings the hope that hard-learned lessons will be incorporated into the next new system. But often operations personnel find their well-intentioned efforts frustrated by an inability to have their inputs considered by design personnel who have strictly-scoped requirements that are coupled with ambitious cost and schedule targets. There is a way for operational inputs to make it into the design, but the solution involves a combination of organizational culture and technical data. Any organization that utilizes this approach can realize significant benefits over the life cycle of their project.

Brady, David A.↗

NASA NTRS2009

Applying Model-based Diagnosis to a Rapid Propellant Loading System

The overall objective of the US Air Force Research Laboratory (AFRL) Rapid Propellant Loading (RPL) Program is to develop a launch vehicle, payload and ground support equipment that can support a rapid propellant load and launch within one hour. NASA Kennedy Space Center (KSC) has been funded by AFRL to develop hardware and software to demonstrate this capability. The key features of the software would be the ability to recognize and adapt to failures in the physical hardware components, advise operators of equipment faults and workarounds, and put the system in a safe configuration if unable to fly. In December 2008 NASA KSC and NASA Ames Research Center (ARC) demonstrated model based simulation and diagnosis capabilities for a scaled-down configuration of the RPL hardware. In this paper we present a description of the model-based technologies that were included as part of this demonstration and the results that were achieved. In continuation of this work we are currently testing the technologies on a simulation of the complete RPL system. Later in the year, when the RPL hardware is ready, we will be integrating these technologies with the real-time operation of the system to provide live state estimates. In future years we will be developing the capability to recover from faulty conditions via redundancy and reconfiguration.

Goodrich, Charlie H.↗

NASA NTRS2011

The Evolution of Utilizing Manual Throttles to Avoid Low LH2 NPSP at the SSME Inlet

Even before the first flight of the Space Shuttle, it was understood low liquid hydrogen (LH2) Net Positive Suction Pressure (NPSP) at the inlet to the Space Shuttle Main Engine (SSME) can have adverse effects on engine operation. A number of failures within both the External Tank (ET) and the Orbiter Main Propulsion System could result in a low LH2 NPSP condition. Operational workarounds were developed to take advantage of the onboard crew s ability to manually throttle down the SSMEs, which alleviated the low LH2 NPSP condition. A throttling down of the SSME resulted in an increase in NPSP, mainly due to the reduction in frictional flow losses while at a lower throttle setting. As engineers refined their understanding of the NPSP requirements for the SSME (through a robust testing program), the operational techniques evolved to take advantage of these additional capabilities. Currently the procedure, which for early Space Shuttle missions required a Return-to-Launch-Site abort, now would result in a nominal Main Engine Cut Off (MECO) and no loss of mission objectives.

Henfling, Rick↗

NASA NTRS2010

The Evolution of Utilizing Manual Throttling to Avoid Excessively Low LH2 NPSP at the SSME Inlet

In the late 1970s, years before the Space Shuttle flew its maiden voyage, it was understood low liquid hydrogen (LH2) Net Positive Suction Pressure (NPSP) at the inlet to the Space Shuttle Main Engine (SSME) could have adverse effects on engine operation. A number of failures within both the External Tank (ET) and the Orbiter Main Propulsion System (MPS) could result in a low LH2 NPSP condition, which at extremely low levels can result in cavitation of SSME turbomachinery. Operational workarounds were developed to take advantage of the onboard crew s ability to manually throttle down the SSMEs (via the Pilot s Speedbrake/Throttle Controller), which alleviated the low LH2 NPSP condition. Manually throttling the SSME to a lower power level resulted in an increase in NPSP, mainly due to the reduction in frictional flow losses while at the lower throttle setting. Early in the Space Shuttle Program s history, the relevant Flight Rule for the Booster flight controller in Mission Control did not distinguish between ET and Orbiter MPS failures and the same crew action was taken for both. However, after a review of all Booster operational techniques following the Challenger disaster in the late 1980s, it was determined manually throttling the SSME to a lower power was only effective for Orbiter MPS failures and the Flight Rule was updated to reflect this change. The Flight Rule and associated crew actions initially called for a single throttle step to minimum power level when a low threshold for NPSP was met. As engineers refined their understanding of the NPSP requirements for the SSME (through a robust testing program), the operational techniques evolved to take advantage of the additional capabilities. This paper will examine the evolution of the Flight rule and associated procedure and how increases in knowledge about the SSME and the Space Shuttle vehicle as a whole have helped shape their development. What once was a single throttle step when NPSP decreased to a certain low threshold has now become three throttle steps, each occurring at a lower NPSP threshold. Additionally the procedure, which for early Space Shuttle missions required a Return-to-Launch-Site abort, now results in a nominal Main Engine Cut Off and no loss of mission objectives.

Henfling, Rick↗

NASA NTRS2011

Making Human Spaceflight Practical and Affordable: Spacecraft Designs and their Degree of Operability

As we push toward new and diverse space transportation capabilities, reduction in operations cost becomes increasingly important. Achieving affordable and safe human spaceflight capabilities will be the mark of success for new programs and new providers. The ability to perceive the operational implications of design decisions is crucial in developing safe yet cost competitive space transportation systems. Any human spaceflight program - government or commercial - must make countless decisions either to implement spacecraft system capabilities or adopt operational constraints or workarounds to account for the lack of such spacecraft capabilities. These decisions can benefit from the collective experience that NASA has accumulated in building and operating crewed spacecraft over the last five decades. This paper reviews NASA s history in developing and operating human rated spacecraft, reviewing the key aspects of spacecraft design and their resultant impacts on operations phase complexity and cost. Specific examples from current and past programs - including the Space Shuttle and International Space Station - are provided to illustrate design traits that either increase or increase cost and complexity associated with spacecraft operations. These examples address factors such as overall design performance margins, levels of redundancy, degree of automated failure response, type and quantity of command and telemetry interfaces, and the definition of reference scenarios for analysis and test. Each example - from early program requirements, design implementation and resulting real-time operations experience - to tell the end-to-end "story" Based on these experiences, specific techniques are recommended to enable earlier and more effective assessment of operations concerns during the design process. A formal method for the assessment of spacecraft operability is defined and results of such operability assessments for recent spacecraft designs are provided. Recent experience in applying these techniques to Orion spacecraft development is reviewed to highlight the direct benefits of early operational assessment and collaborative development efforts.

Crocker, Alan R.↗

NASA NTRS2011

Planetary Education and Outreach Using the NOAA Science on a Sphere

Science On a Sphere (SOS) is a large visualization system, developed by the National Oceanic and Atmospheric Administration (NOAH), that uses computers running Redhat Linux and four video projectors to display animated data onto the outside of a sphere. Said another way, SOS is a stationary globe that can show dynamic, animated images in spherical form. Visualization of cylindrical data maps show planets, their atmosphere, oceans, and land, in very realistic form. The SOS system uses 4 video projectors to display images onto the sphere. Each projector is driven by a separate computer, and a fifth computer is used to control the operation of the display computers. Each computer is a relatively powerful PC with a high-end graphics card. The video projectors have native XGA resolution. The projectors are placed at the corners of a 30' x 30' square with a 68" carbon fiber sphere suspended in the center of the square. The equator of the sphere is typically located 86" off the floor. SOS uses common image formats such as JPEG, or TIFF in a very specific, but simple form; the images are plotted on an equatorial cylindrical equidistant projection, or as it is commonly known, a latitude/longitude grid, where the image is twice as wide as it is high (rectangular). 2048x] 024 is the minimum usable spatial resolution without some noticeable pixelation. Labels and text can be applied within the image, or using a timestamp-like feature within the SOS system software. There are two basic modes of operation for SOS: displaying a single image or an animated sequence of frames. The frame or frames can be setup to rotate or tilt, as in a planetary rotation. Sequences of images that animate through time produce a movie visualization, with or without an overlain soundtrack. After the images are processed, SOS will display the images in sequence and play them like a movie across the entire sphere surface. Movies can be of any arbitrary length, limited mainly by disk space and can be animated at frame rates up to 30 frames per second. Transitions, special effects, and other computer graphics techniques can be added to a sequence through the use of off-the-shelf software, like Final Cut Pro. However, one drawback is that the Sphere cannot be used in the same manner as a flat movie screen; images cannot be pushed to a "side", a highlighted area must be viewable to all sides of the room simultaneously, and some transitions do not work as well as others. We discuss these issues and workarounds in our poster.

Simon-Miller, A. A.↗

NASA NTRS2011

The Evolution of Utilizing Manual Throttles to Avoid Excessively Low LH2 NPSP at the SSME Inlet

In the late 1970s, years before the Space Shuttle flew its maiden voyage, it was understood low liquid hydrogen (LH2) Net Positive Suction Pressure (NPSP) at the inlet to the Space Shuttle Main Engine (SSME) could have adverse effects on engine operation. A number of failures within both the External Tank (ET) and the Orbiter Main Propulsion System (MPS) could result in a low LH2 NPSP condition, which at extremely low levels can result in cavitation of SSME turbomachinery. Operational workarounds were developed to take advantage of the onboard crew s ability to manually throttle down the SSMEs (via the Pilot s Speedbrake/Throttle Controller), which alleviated the low LH2 NPSP condition. Manually throttling the SSME to a lower power level resulted in an increase in NPSP, mainly due to the reduction in frictional flow losses while at the lower throttle setting. Early in the Space Shuttle Program s history, the relevant Flight Rule for the Booster flight controllers in Mission Control did not distinguish between ET and Orbiter MPS failures and the same crew action was taken for both. However, after a review of all Booster operational techniques following the Challenger disaster in the late 1980s, it was determined manually throttling the SSME to a lower power was only effective for Orbiter MPS failures and the Flight Rule was updated to reflect this change. The Flight Rule and associated crew actions initially called for a single throttle step to minimum power level when a low threshold for NPSP was met. As engineers refined their understanding of the NPSP requirements for the SSME (through a robust testing program), the operational techniques evolved to take advantage of the additional capabilities. This paper will examine the evolution of the Flight rule and associated procedure and how increases in knowledge about the SSME and the Space Shuttle vehicle as a whole have helped shape their development. What once was a single throttle step when NPSP decreased to a certain threshold has now become three throttle steps, each occurring at a lower NPSP threshold. Additionally the procedure, which for early Space Shuttle missions required a Return-to-Launch-Site abort, now results in a nominal Main Engine Cut Off and no loss of mission objectives.

Henfling, Rick↗

NASA NTRS2007

United Space Alliance LLC Parachute Refurbishment Facility Model

The Parachute Refurbishment Facility Model was created to reflect the flow of hardware through the facility using anticipated start and delivery times from a project level IV schedule. Distributions for task times were built using historical build data for SFOC work and new data generated for CLV/ARES task times. The model currently processes 633 line items from 14 SFOC builds for flight readiness, 16 SFOC builds returning from flight for defoul, wash, and dry operations, 12 builds for CLV manufacturing operations, and 1 ARES 1X build. Modeling the planned workflow through the PRF is providing a reliable way to predict the capability of the facility as well as the manpower resource need. Creating a real world process allows for real world problems to be identified and potential workarounds to be implemented in a safe, simulated world before taking it to the next step, implementation in the real world.

Esser, Valerie↗

NASA NTRS2008

The Application of the Human Engineering Modeling and Performance Laboratory for Space Vehicle Ground Processing Tasks at Kennedy Space Center

The introduction of United Space Alliance's Human Engineering Modeling and Performance Laboratory began in early 2007 in an attempt to address the problematic workspace design issues that the Space Shuttle has imposed on technicians performing maintenance and inspection operations. The Space Shuttle was not expected to require the extensive maintenance it undergoes between flights. As a result, extensive, costly resources have been expended on workarounds and modifications to accommodate ground processing personnel. Consideration of basic human factors principles for design of maintenance is essential during the design phase of future space vehicles, facilities, and equipment. Simulation will be needed to test and validate designs before implementation.

Woodbury, Sarah K.↗

NASA NTRS2015

ISS Regenerative Life Support: Challenges and Success in the Quest for Long-Term Habitability in Space

The International Space Station's (ISS) Regenerative Environmental Control and Life Support System (ECLSS) was launched in 2008 to continuously recycle urine and crew sweat into drinking water and oxygen using brand new technologies. This functionality was highly important to the ability of the ISS to transition to the long-term goal of 6-crew operations as well as being critical tests for long-term space habitability. Through the initial activation and long-term operations of these systems, important lessons were learned about the importance of system redundancy and operational workarounds that allow Systems Engineers to maintain functionality with limited on-orbit spares. This presentation will share some of these lessons learned including how to balance water through the different systems, store and use water for use in system failures and creating procedures to operate the systems in ways that they were not initially designed to do.

Bazley, Jesse↗

NASA NTRS2016

Development of a Prototype Model-Form Uncertainty Knowledge Base

Uncertainties are generally classified as either aleatory or epistemic. Aleatory uncertainties are those attributed to random variation, either naturally or through manufacturing processes. Epistemic uncertainties are generally attributed to a lack of knowledge. One type of epistemic uncertainty is called model-form uncertainty. The term model-form means that among the choices to be made during a design process within an analysis, there are different forms of the analysis process, which each give different results for the same configuration at the same flight conditions. Examples of model-form uncertainties include the grid density, grid type, and solver type used within a computational fluid dynamics code, or the choice of the number and type of model elements within a structures analysis. The objectives of this work are to identify and quantify a representative set of model-form uncertainties and to make this information available to designers through an interactive knowledge base (KB). The KB can then be used during probabilistic design sessions, so as to enable the possible reduction of uncertainties in the design process through resource investment. An extensive literature search has been conducted to identify and quantify typical model-form uncertainties present within aerospace design. An initial attempt has been made to assemble the results of this literature search into a searchable KB, usable in real time during probabilistic design sessions. A concept of operations and the basic structure of a model-form uncertainty KB are described. Key operations within the KB are illustrated. Current limitations in the KB, and possible workarounds are explained.

Green, Lawrence L.↗

NASA NTRS2015

Precise Pointing for Radio Science Occultations and Radar Mapping During the Cassini Mission at Saturn

This paper discusses the implementation challenges and lessons learned from radar and radio science pointing observations during the Cassini mission at Saturn. Implementation of the precise desired pointing reveals key issues in the ground system, the flight system, and the pointing paradigm itself. To achieve accurate pointing on some observations, specific workarounds had to be implemented and folded into the sequence development process. Underlying Cassini's pointing system is a remarkable construct known as Inertial Vector Propagation.

Burk, Thomas A.↗

NASA NTRS2016

Thomas Leps Internship Abstract

An optical navigation system is being flown as the backup system to the primary Deep Space Network telemetry for navigation and guidance purposes on Orion. This is required to ensure Orion can recover from a loss of communication, which would simultaneously cause a loss of DSN telemetry. Images taken of the Moon and Earth are used to give range and position information to the navigation computer for trajectory calculations and maneuver execution. To get telemetry data from these images, the size and location of the moon need to be calculated with high accuracy and precision. The reentry envelope for the Orion EM-1 mission requires the centroid and radius of the moon images to be determined within 1/3 of a pixel 3 sigma. In order to ensure this accuracy and precision can be attained, I was tasked with building precise dot grid images for camera calibration as well as building a hardware in the loop test stand for flight software and hardware proofing. To calibrate the Op-Nav camera a dot grid is imaged with the camera, the error between the image dot location and the actual dot location can be used to build a distortion map of the camera and lens system so that images can be fixed to display truth locations. To build the dot grid images I used the Electro Optics Lab optical bench Bright Object Simulator System, and gimbal. The gimbal was slewed to a series of elevations and azimuths. An image of the collimated single point light source was then taken at each position. After a series of 99 images were taken at different locations the single light spots were extracted from each image and added to a composite image containing all 99 points. During the development of these grids it was noticed that an intermittent error in the artificial "star" locations occurred. Prior to the summer this error was attributed to the gimbal having glitches in it's pointing direction and was going to be replaced, however after further examining the issue I determined it to be a software issue. I have since narrowed the likely source of the error down to a Software Development Kit released by the camera supplier PixeLink. I have since developed a workaround in order to build star grids for calibration until the software bug can be isolated and fixed. I was also tasked with building a Hardware in the Loop test stand in order to test the full Op-Nav system. A 4k screen displays simulated Lunar and Terrestrial images from a possible Orion trajectory. These images are then projected through a collimator and then captured with an Op-Nav camera controlled by an Intel NUC computer running flight software. The flight software then analyzes the images to determine attitude and position, this data is then reconstructed into a trajectory and matched to the simulated trajectory in order to determine the accuracy of the attitude and position estimates. In order for the system to work it needs to be precisely and accurately aligned. I developed an alignment procedure that allows the screen, collimator and camera to be squared, centered and collinear with each other within a micron spatially and 5 arcseconds in rotation. I also designed a rigid mount for the screen that was machined on site in Building 10 by another intern. While I was working in the EOL we received a $500k Orion startracker for alignment procedure testing. Due to my prior experience in electronics development, as an ancillary duty, I was tasked with building the cables required to operate and power the startracker. If any errors are made building these cables the startracker would be destroyed, I was honored that the director of the lab entrusted such a critical component with me. This internship has cemented my view on public space exploration. I always preferred public sector to privatization because, as a scientist, the most interesting aspects of space for me are not necessarily the most profitable. I was concerned that the public sector was faltering however, and that in order to improve human space exploration I would be forced into private sector. I now know that, at least at JSC, human spaceflight is still progressing, and exciting work is still being done. I am now actively seeking employment at JSC after I complete my Ph.D and have met with my branch chiefs and mentor to discuss transitioning to a grad Co-op position.

Leps, Thomas↗

NASA NTRS2016

Essential SpaceWire Hardware Capabilities for a Robust Network

The Geostationary Operational Environmental Satellite R-Series Program (GOES-R) mission is a joint program between National Oceanic & Atmospheric Administration (NOAA) and National Aeronautics & Space Administration (NASA) Goddard Space Flight Center (GSFC). GOES-R project selected SpaceWire as the best solution to satisfy the desire for simple and flexible instrument to spacecraft command and telemetry communications. GOES-R development and integration is complete and the observatory is scheduled for launch October 2016. The spacecraft design was required to support redundant SpaceWire links for each instrument side, as well as to route the fewest number of connections through a Slip Ring Assembly necessary to support Solar pointing instruments. The final design utilized two different router designs. The SpaceWire standard alone does not ensure the most practical or reliable network. On GOES-R a few key hardware capabilities were identified that merit serious consideration for future designs. Primarily these capabilities address persistent port stalls and the prevention of receive buffer overflows. Workarounds were necessary to overcome shortcomings that could be avoided in future designs if they utilize the capabilities, discussed in this paper, above and beyond the requirements of the SpaceWire standard.

SpaceWire↗

NASA NTRS2018

Considerations When Building Thermal Models that Require Conversion Between Formats

At times, it is inevitable to require conversion of thermal models from one software format to another. This most often occurs for missions with international partners where not all parties utilize the same software packages for thermal analysis. Mandating a single tool for all parties is one possible solution, but this approach can introduce problems if significant effort is required to overcome inexperience with the designated tool and may result in difficulty meeting analysis schedule requirements. Alternatively, allowing all parties to use their own familiar tools minimizes the impact to analysis schedules but does introduce the need to convert the models later to a common format for analysis at a higher level of assembly. External conversion tools and formats have been developed through the years to aid in this process, but have had limited success in fully converting models seamlessly. Having a basic familiarity with tool capabilities on both sides of the conversion process allows for models to be built in a manner to better facilitate conversion by avoiding features and capabilities which are unsupported by the destination tool or for which no workarounds exist. Also, the effort to convert a model is often neglected when developing the schedules for analysis at the higher assembly levels; delivery of models preconditioned for convertibility minimizes the schedule risk. This paper seeks to provide some guidance on modeling techniques to avoid when developing Geometrical Math Models (GMM) and Thermal Math Models (TMM) when conversion is required. The recommendations are based on GMM conversion experiences between TSS/ThermalDesktop/ESARAD and TMM conversions between SINDA-FLUINT/ESATAN.

Modeling↗

NASA NTRS2019

SCREAM: Space-based Cognitive Reliability Error Analysis Method

Given both ground-based performance shaping factors (PSFs) collected by the U.S. Nuclear Regulatory Commission (USNRC) and potential space-based PSFs collected by JSC's HH&P, this year's task is to determine how to combine them for future human reliability analysis (HRA) of space missions. All HRA to date for space missions have been based on ground data (i.e. 1-G environment). There is no space-based HRA approach. The target of this project to produce a "first of its kind" HRA approach for space missions. As humans go beyond Earth orbit and missions become longer, human performance and reliability is expected to degrade. The questions become by how much, when, and what, leading to defining the overall effect on crew risk. Knowing this information earlier rather than later will help us mitigate this risk by vehicle design, crew training, and operational workarounds.

Boyer, Roger L.↗

NASA NTRS2019

Challenges Using Linux as a Real-Time Operating System

Human-in-the-loop (HITL) simulation groups at NASA and the Air Force Research Lab have been using Linux as a real-time operating system (RTOS) for over a decade. More recently, SpaceX has revealed that it is using Linux as an RTOS for its Falcon launch vehicles and Dragon capsules. As Linux makes its way from ground facilities to flight critical systems, it is necessary to recognize that the real-time capabilities in Linux are cobbled onto a kernel architecture designed for general purpose computing. The Linux kernel contain numerous design decisions that favor throughput over determinism and latency. These decisions often require workarounds in the application or customization of the kernel to restore a high probability that Linux will achieve deadlines.

Madden, Michael M.↗

NASA NTRS2019

Challenges Using the Linux Network Stack for Real-Time Communication

Starting in the early 2000s, human-in-the-loop (HITL) simulation groups at NASA and the Air Force Research Lab began using the Linux network stack for some real-time communication. More recently, SpaceX has adopted Ethernet as the primary bus technology for its Falcon launch vehicles and Dragon capsules. As the Linux network stack makes its way from ground facilities to flight critical systems, it is necessary to recognize that the network stack is optimized for communication over the open Internet, which cannot provide latency guarantees. The Internet protocols and their implementation in the Linux network stack contain numerous design decisions that favor throughput over determinism and latency. These decisions often require workarounds in the application or customization of the stack to maintain a high probability of low latency on closed networks, especially if the network must be fault tolerant to single event upsets.

Madden, Michael M.↗