Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Timeline”

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 1,027 records · Page 57
All sourcesNASA NTRSDOE OSTI
NASA NTRS2011

Flight Planning Branch Space Shuttle Lessons Learned

Planning products and procedures that allow the mission flight control teams and the astronaut crews to plan, train and fly every Space Shuttle mission have been developed by the Flight Planning Branch at the NASA Johnson Space Center. As the Space Shuttle Program ends, lessons learned have been collected from each phase of the successful execution of these Shuttle missions. Specific examples of how roles and responsibilities of console positions that develop the crew and vehicle attitude timelines will be discussed, as well as techniques and methods used to solve complex spacecraft and instrument orientation problems. Additionally, the relationships and procedural hurdles experienced through international collaboration have molded operations. These facets will be explored and related to current and future operations with the International Space Station and future vehicles. Along with these important aspects, the evolution of technology and continual improvement of data transfer tools between the shuttle and ground team has also defined specific lessons used in the improving the control teams effectiveness. Methodologies to communicate and transmit messages, images, and files from Mission Control to the Orbiter evolved over several years. These lessons have been vital in shaping the effectiveness of safe and successful mission planning that have been applied to current mission planning work in addition to being incorporated into future space flight planning. The critical lessons from all aspects of previous plan, train, and fly phases of shuttle flight missions are not only documented in this paper, but are also discussed as how they pertain to changes in process and consideration for future space flight planning.

Price, Jennifer B.↗
NASA NTRS2011

Reverse Launch Abort System Parachute Architecture Trade Study

This study investigated a potential Launch Abort System (LAS) Concept of Operations and abort parachute architecture. The purpose of the study was to look at the concept of jettisoning the LAS tower forward (Reverse LAS or RLAS) into the free-stream flow rather than after reorienting to a heatshield forward orientation. A hypothesized benefit was that due to the compressed timeline the dynamic pressure at main line stretch would be substantially less. This would enable the entry parachutes to be designed and sized based on entry loading conditions rather than the current stressing case of a Pad Abort. Ultimately, concerns about the highly dynamic reorientation of the CM via parachutes, and the additional requirement of a triple bridle attachment for the RLAS parachute system, overshadowed the potential benefits and ended this effort.

Litton, Daniel K.↗
NASA NTRS2011

Flight Dynamics Operations: Methods and Lessons Learned from Space Shuttle Orbit Operations

The Flight Dynamics Officer is responsible for trajectory maintenance of the Space Shuttle. This paper will cover high level operational considerations, methodology, procedures, and lessons learned involved in performing the functions of orbit and rendezvous Flight Dynamics Officer and leading the team of flight dynamics specialists during different phases of flight. The primary functions that will be address are: onboard state vector maintenance, ground ephemeris maintenance, calculation of ground and spacecraft acquisitions, collision avoidance, burn targeting for the primary mission, rendezvous, deorbit and contingencies, separation sequences, emergency deorbit preparation, mass properties coordination, payload deployment planning, coordination with the International Space Station, and coordination with worldwide trajectory customers. Each of these tasks require the Flight Dynamics Officer to have cognizance of the current trajectory state as well as the impact of future events on the trajectory plan in order to properly analyze and react to real-time changes. Additionally, considerations are made to prepare flexible alternative trajectory plans in the case timeline changes or a systems failure impact the primary plan. The evolution of the methodology, procedures, and techniques used by the Flight Dynamics Officer to perform these tasks will be discussed. Particular attention will be given to how specific Space Shuttle mission and training simulation experiences, particularly off-nominal or unexpected events such as shortened mission durations, tank failures, contingency deorbit, navigation errors, conjunctions, and unexpected payload deployments, have influenced the operational procedures and training for performing Space Shuttle flight dynamics operations over the history of the program. These lessons learned can then be extended to future vehicle trajectory operations.

Cutri-Kohart, Rebecca M.↗
NASA NTRS2010

ISS/STS Ground Status at KSC

This slide presentation reviews the status of several shuttle missions. It includes a timeline for three STS missions (i.e., OV-103, OV-104, and OV-105), and specific information about each mission, and the status of the shuttle that is to be used

Kirkpatrick, Paul↗
NASA NTRS2011

Spacecraft Conceptual Design Compared to the Apollo Lunar Lander

Future human exploration of the Moon will require an optimized spacecraft design with each sub-system achieving the required minimum capability and maintaining high reliability. The objective of this study was to trade capability with reliability and minimize mass for the lunar lander spacecraft. The NASA parametric concept for a 3-person vehicle to the lunar surface with a 30% mass margin totaled was considerably heavier than the Apollo 15 Lunar Module "as flown" mass of 16.4 metric tons. The additional mass was attributed to mission requirements and system design choices that were made to meet the realities of modern spaceflight. The parametric tool used to size the current concept, Envision, accounts for primary and secondary mass requirements. For example, adding an astronaut increases the mass requirements for suits, water, food, oxygen, as well as, the increase in volume. The environmental control sub-systems becomes heavier with the increased requirements and more structure was needed to support the additional mass. There was also an increase in propellant usage. For comparison, an "Apollo-like" vehicle was created by removing these additional requirements. Utilizing the Envision parametric mass calculation tool and a quantitative reliability estimation tool designed by Valador Inc., it was determined that with today?s current technology a Lunar Module (LM) with Apollo capability could be built with less mass and similar reliability. The reliability of this new lander was compared to Apollo Lunar Module utilizing the same methodology, adjusting for mission timeline changes as well as component differences. Interestingly, the parametric concept's overall estimated risk for loss of mission (LOM) and loss of crew (LOC) did not significantly improve when compared to Apollo.

Young, C.↗
NASA NTRS2008

Ares I Integration Approach

This slide presentation reviews the planned Integration approach for the Ares I Launch vehicle. It includes organization charts, and diagrams showing responsibilities for the various activities of the launch. Included is also a timeline with milestones for the project.

Reuter, Jim↗
NASA NTRS2010

Design and Implementation of the Boundary Layer Transition Flight Experiment on Space Shuttle Discovery

In an effort to better the understanding of high speed aerodynamics, a series of flight experiments were installed on Space Shuttle Discovery during the STS-119 and STS-128 missions. This experiment, known as the Boundary Layer Transition Flight Experiment (BLTFE), provided the technical community with actual entry flight data from a known height protuberance at Mach numbers at and above Mach 15. Any such data above Mach 15 is irreproducible in a laboratory setting. Years of effort have been invested in obtaining this valuable data, and many obstacles had to be overcome in order to ensure the success of implementing an Orbiter modification. Many Space Shuttle systems were involved in the installation of appropriate components that revealed 'concurrent engineering' was a key integration tool. This allowed the coordination of all various parts and pieces which had to be sequenced appropriately and installed at the right time. Several issues encountered include Orbiter configuration and access, design requirements versus current layout, implementing the modification versus typical processing timelines, and optimizing the engineering design cycles and changes. Open lines of communication within the entire modification team were essential to project success as the team was spread out across the United States, from NASA Kennedy Space Center in Florida, to NASA Johnson Space Center in Texas, to Boeing Huntington Beach, California among others. The forum permits the discussion of processing concerns from the design phase to the implementation phase, which eventually saw the successful flights and data acquisition on STS-119 in March 2009 and on STS-128 in September 2009.

Spanos, Theodoros A.↗
NASA NTRS2011

Modeling Constellation Virtual Missions Using the Vdot(Trademark) Process Management Tool

The authors have identified a software tool suite that will support NASA's Virtual Mission (VM) effort. This is accomplished by transforming a spreadsheet database of mission events, task inputs and outputs, timelines, and organizations into process visualization tools and a Vdot process management model that includes embedded analysis software as well as requirements and information related to data manipulation and transfer. This paper describes the progress to date, and the application of the Virtual Mission to not only Constellation but to other architectures, and the pertinence to other aerospace applications. Vdot s intuitive visual interface brings VMs to life by turning static, paper-based processes into active, electronic processes that can be deployed, executed, managed, verified, and continuously improved. A VM can be executed using a computer-based, human-in-the-loop, real-time format, under the direction and control of the NASA VM Manager. Engineers in the various disciplines will not have to be Vdot-proficient but rather can fill out on-line, Excel-type databases with the mission information discussed above. The author s tool suite converts this database into several process visualization tools for review and into Microsoft Project, which can be imported directly into Vdot. Many tools can be embedded directly into Vdot, and when the necessary data/information is received from a preceding task, the analysis can be initiated automatically. Other NASA analysis tools are too complex for this process but Vdot automatically notifies the tool user that the data has been received and analysis can begin. The VM can be simulated from end-to-end using the author s tool suite. The planned approach for the Vdot-based process simulation is to generate the process model from a database; other advantages of this semi-automated approach are the participants can be geographically remote and after refining the process models via the human-in-the-loop simulation, the system can evolve into a process management server for the actual process.

Hardy, Roger↗
NASA NTRS2010

Reinventing User Applications for Mission Control

In 2006, NASA Ames Research Center's (ARC) Intelligent Systems Division, and NASA Johnson Space Centers (JSC) Mission Operations Directorate (MOD) began a collaboration to move user applications for JSC's mission control center to a new software architecture, intended to replace the existing user applications being used for the Space Shuttle and the International Space Station. It must also carry NASA/JSC mission operations forward to the future, meeting the needs for NASA's exploration programs beyond low Earth orbit. Key requirements for the new architecture, called Mission Control Technologies (MCT) are that end users must be able to compose and build their own software displays without the need for programming, or direct support and approval from a platform services organization. Developers must be able to build MCT components using industry standard languages and tools. Each component of MCT must be interoperable with other components, regardless of what organization develops them. For platform service providers and MOD management, MCT must be cost effective, maintainable and evolvable. MCT software is built from components that are presented to users as composable user objects. A user object is an entity that represents a domain object such as a telemetry point, a command, a timeline, an activity, or a step in a procedure. User objects may be composed and reused, for example a telemetry point may be used in a traditional monitoring display, and that same telemetry user object may be composed into a procedure step. In either display, that same telemetry point may be shown in different views, such as a plot, an alpha numeric, or a meta-data view and those views may be changed live and in place. MCT presents users with a single unified user environment that contains all the objects required to perform applicable flight controller tasks, thus users do not have to use multiple applications, the traditional boundaries that exist between multiple heterogeneous applications disappear, leaving open the possibility of new operations concepts that are not constrained by the traditional applications paradigm.

Trimble, Jay Phillip↗
NASA NTRS2010

Kepler Science Operations Center Architecture

We give an overview of the operational concepts and architecture of the Kepler Science Data Pipeline. Designed, developed, operated, and maintained by the Science Operations Center (SOC) at NASA Ames Research Center, the Kepler Science Data Pipeline is central element of the Kepler Ground Data System. The SOC charter is to analyze stellar photometric data from the Kepler spacecraft and report results to the Kepler Science Office for further analysis. We describe how this is accomplished via the Kepler Science Data Pipeline, including the hardware infrastructure, scientific algorithms, and operational procedures. The SOC consists of an office at Ames Research Center, software development and operations departments, and a data center that hosts the computers required to perform data analysis. We discuss the high-performance, parallel computing software modules of the Kepler Science Data Pipeline that perform transit photometry, pixel-level calibration, systematic error-correction, attitude determination, stellar target management, and instrument characterization. We explain how data processing environments are divided to support operational processing and test needs. We explain the operational timelines for data processing and the data constructs that flow into the Kepler Science Data Pipeline.

Middour, Christopher↗
NASA NTRS2011

A Hybrid Parachute Simulation Environment for the Orion Parachute Development Project

A parachute simulation environment (PSE) has been developed that aims to take advantage of legacy parachute simulation codes and modern object-oriented programming techniques. This hybrid simulation environment provides the parachute analyst with a natural and intuitive way to construct simulation tasks while preserving the pedigree and authority of established parachute simulations. NASA currently employs four simulation tools for developing and analyzing air-drop tests performed by the CEV Parachute Assembly System (CPAS) Project. These tools were developed at different times, in different languages, and with different capabilities in mind. As a result, each tool has a distinct interface and set of inputs and outputs. However, regardless of the simulation code that is most appropriate for the type of test, engineers typically perform similar tasks for each drop test such as prediction of loads, assessment of altitude, and sequencing of disreefs or cut-aways. An object-oriented approach to simulation configuration allows the analyst to choose models of real physical test articles (parachutes, vehicles, etc.) and sequence them to achieve the desired test conditions. Once configured, these objects are translated into traditional input lists and processed by the legacy simulation codes. This approach minimizes the number of sim inputs that the engineer must track while configuring an input file. An object oriented approach to simulation output allows a common set of post-processing functions to perform routine tasks such as plotting and timeline generation with minimal sensitivity to the simulation that generated the data. Flight test data may also be translated into the common output class to simplify test reconstruction and analysis.

Moore, James W.↗
NASA NTRS2004

Creating a Scenario Suitable for Multiple Caregivers

The HPS can be utilized for the training of a wide variety of caregivers, ranging from physicians to laypeople. Methods: A single scenario was developed and adapted for a number of clinical scenarios and operational environments, ranging from in-flight to the immediate postflight timeline. In this way, different caregivers, from astronauts to search and rescue forces to specialty-boarded physicians, could make use of a single clinical situation. Five crew medical officer analogs and sixty anesthesia residents, serving as flight surgeon analogs, and, were briefed on space medicine and physiology, then were exposed to the scenario and asked to manage the patient as if they were part of the in-flight or recovery team. Results: Basic themes, such as crisis resource management, were standard across the student audiences. Discussion: A single clinical script can easily be adapted for multiple uses.

Doerr, Harold↗
NASA NTRS2003

The NEEMO Project: A Report on how NASA Utilizes the "Aquarius" Undersea Habitat as an Analog for Long-Duration Space Flight

NEEMO is the NASA Extreme Environment Mission Operations, a cooperative project between NASA and the National Oceanic and Atmospheric Administration (NOAA). NEEMO was created and is managed by the Mission Operations Directorate at the Johnson Space Center in Houston, Texas. On the NOAA side, the National Undersea Research Center (NURC) in Key Largo, FL, with the help of the University of North Carolina at Wilmington, manages and operates the Aquarius Program. NEEMO was developed by astronaut training specialists to utilize an undersea research habitat as a multi-objective mission analog for long-duration space flight. Each mission was designed to expose astronauts to extreme environments for training purposes and to research crew behavior, habitability, and space analog life sciences. All of this was done much in the model of a space mission utilizing specific crew procedures, mission rules and timelines. Objectives of the missions were very diverse and contained many of the typical space mission type activities such as EV As (also known as extra vehicular activities), in-habitat science and research, and educational, public outreach, and media events. Five missions, dubbed NEEMO 1-5, were conducted between October 2001 and July 2003, the longest of which (NEEMO 5) lasted 14 days.

Reagan, Marc↗
NASA NTRS2000

Orbiter Capability for Providing Water to the International Space Station according to the Most Probable Flight Attitudes

Water to be generated by, delivered to, and processed by the International Space Station (ISS) is a critical Environmental Control and Life Support (ECLS) element, especially for the early ISS missions. A significant portion of the water required by the ISS shall be provided by the Shuttle Transportation System (STS) Orbiter. The balance of water generated by the Orbiter Fuel Cells (FC), minus that water consumed by the Orbiter Flash Evaporator System (FES) and crew, is available for transfer to the ISS. During later missions, crew respired and perspired water, as well as effluent water from the Orbiter LiOH canisters, will be collected as condensate and available for transfer to the ISS. Orbiter radiator performance provides the most variance in determining the amount of net Orbiter water available for transfer to the ISS. As radiator performance decreases, the dependence upon the FES (and FC water) increases for rejecting Orbiter waste heat. Generally, radiator performance decreases as the ISS assembly size increases (especially as solar arrays are added), and also as beta angle increases. ISS solar array deployment necessitates the use of models with articulating solar arrays (for Earth local-vertical attitudes), as array position dramatically affects Orbiter radiator performance. Recent developments in the relaxation of beta angle limitations have also increased the complexity and difficulty of providing water to the ISS. Other factors that may hinder the ability to transfer water are the number of empty Contingency Water Containers (CWCs) available, duration of open-hatch time, crew activity timeline, and full CWC storage capability. A parametric study has been accomplished that provides a quick-reference table for determining expected water generation rates for ISS missions 2A.2 through 7A.1. An hourly Orbiter water generation rate is reported according to a matrix that consists of: (1) (six) significant changes in ISS assembly configuration; (2) (four) beta angles (0 deg. , +37 deg., +53 deg. , and +75 deg.); (3) the (three) most representative ISS attitudes (XPOP-O, XPOP-180 and +XVV); (4) (four) Orbiter radiator configurations (both stowed, starboard deployed, port deployed, and both deployed) and (5) the (two) conditions (radiator inlet temperatures and fuel cell power) most consistent with sleep and wake periods. Those permutations of higher probability of occurrence than others have been identified. Another parametric study has been accomplished that provides a quick-reference table for determining expected water generation rates for ISS assembly complete missions. An hourly Orbiter water generation rate is reported according to a matrix that consists of: (1) (seven) beta angles (-75 deg., -60 deg., -30 deg., 0 deg., +30 deg., +60 deg., and +75 deg.); (2) the (nine) PYR angles that define the corners of the envelope; (3) (four) Orbiter radiator configurations (both stowed, starboard deployed, port deployed, and both deployed) and (4) the (two) conditions (radiator inlet temperatures and fuel cell power) most consistent with sleep and wake periods.

Dunaway, Brian↗
NASA NTRS2010

NASA's Soil Moisture Active and Passive (SMAP) Mission

The Soil Moisture Active-Passive (SMAP) Mission is one of the first Earth observation satellites being formulated by NASA in response to the 2007 National Research Council s Decadal Survey. SMAP will make global measurements of soil moisture at the Earth's land surface and its freeze-thaw state. These measurements will allow significantly improved estimates of water, energy and carbon transfers between the land and atmosphere. Soil moisture measurements are also of great importance in assessing flooding and monitoring drought. Knowledge gained from SMAP observations can help mitigate these natural hazards, resulting in potentially great economic and social benefits. SMAP observations of soil moisture and freeze/thaw timing over the boreal latitudes will also reduce a major uncertainty in quantifying the global carbon balance and help to resolve an apparent missing carbon sink over land. The SMAP mission concept will utilize an L-band radar and radiometer sharing a rotating 6-meter mesh reflector antenna flying in a 680 km polar orbit with an 8-day exact ground track repeat aboard a 3-axis stabilized spacecraft to provide high-resolution and high-accuracy global maps of soil moisture and freeze/thaw state every two to three days. In addition, the SMAP project will use these surface observations with advanced modeling and data assimilation to provide estimates of deeper root-zone soil moisture and net ecosystem exchange of carbon. SMAP recently completed its Phase A Mission Concept Study Phase for NASA and transitioned into Phase B (Formulation and Detailed Design). A number of significant accomplishments occurred during this initial phase of mission development. The SMAP project held several open meetings to solicit community feedback on possible science algorithms, prepared preliminary draft Algorithm Theoretical Basis Documents (ATBDs) for each mission science product, and established a prototype algorithm testbed to enable testing and evaluation of the performance of candidate algorithms. SMAP conducted an Applications Workshop in September 2009 to coordinate with potential application users interested in the mission data. A draft Applications Plan describing the Project s planned outreach to potential applications users has been prepared and will be updated during Phase B. SMAP made a significant evaluation of the potential terrestrial radio frequency interference (RFI) source environment and established radiometer and radar flight hardware and ground processing mitigation approaches. SMAP finalized its science orbit and orbit injection approach to optimize launch mass and prepared launch and commissioning scenarios and timeline. A science data communications approach was developed to maximize available science data volume to improve science margins while maintaining moderately short data product latencies to support many potential applications using existing ground assets and with minimum impact to the flight system. SMAP developed rigid multi-body and flexible body dynamics and control models and system designs for the 6-meter rotating instrument reflector-boom assembly (RBA) and flight system to confirm pointing and control performance, and devised strategies to efficiently implement on-orbit balancing if needed. Industry partners were selected for the spin mechanism assembly (SMA) and RBA. Preliminary designs for the radar and radiometer were initiated, including constructing breadboards of key assemblies.

Kellogg, Kent↗
NASA NTRS2010

IVS Working Group 4: VLBI Data Structures

In 2007 the IVS Directing Board established IVS Working Group 4 on VLBI Data Structures. This note discusses the current VLBI data format, goals for a new format, the history and formation of the Working Group, and a timeline for the development of a new VLBI data format.

Gipson, John↗
NASA NTRS2010

Supersonics Project - Airport Noise Tech Challenge

The Airport Noise Tech Challenge research effort under the Supersonics Project is reviewed. While the goal of "Improved supersonic jet noise models validated on innovative nozzle concepts" remains the same, the success of the research effort has caused the thrust of the research to be modified going forward in time. The main activities from FY06-10 focused on development and validation of jet noise prediction codes. This required innovative diagnostic techniques to be developed and deployed, extensive jet noise and flow databases to be created, and computational tools to be developed and validated. Furthermore, in FY09-10 systems studies commissioned by the Supersonics Project showed that viable supersonic aircraft were within reach using variable cycle engine architectures if exhaust nozzle technology could provide 3-5dB of suppression. The Project then began to focus on integrating the technologies being developed in its Tech Challenge areas to bring about successful system designs. Consequently, the Airport Noise Tech Challenge area has shifted efforts from developing jet noise prediction codes to using them to develop low-noise nozzle concepts for integration into supersonic aircraft. The new plan of research is briefly presented by technology and timelines.

Bridges, James↗
NASA NTRS2011

An Overview of STS-132 MRM1 Cargo Element Thermal Model Development and Analyses

STS-132 was launched in May 2010 and delivered the Russian Mini Research Module 1 (MRM1) cargo element to the International Space Station as part of the ULF-4 assembly flight. The cargo element consisted of the module outfitted with externally mounted Multi-purpose Laboratory Module (MLM) Airlock, MLM radiator, Portable Work Platform (PWP), and a European Robotic Arm (ERA) spare elbow. Prior to every Shuttle flight, hardware developers are required to determine compatibility of their hardware to thermal environments experienced during the Shuttle mission and once the element is integrated with the ISS. Thermal models are provided to the Shuttle program to determine the impact of the payload on the Orbiter hardware, as well as the ISS program to determine impacts on other ISS payloads in the Orbiter. Historically the Russian International Partner (IP) develops models in formats not compatible with software used by Space Shuttle or ISS programs. This prompted NASA and Lockheed Martin to develop a unique set of thermal models for the MRM1 cargo element. Subsequent ULF-4 mission analyses performed with the models assessed the launch to activation response, identified operational criteria documented in flight rules, and ensured compliance with the mission timeline and no hazards to the crew, orbiter, or ISS. This presentation provides an overview of the work performed, depicts unique approaches in model development, discusses lessons learned, and issue resolution approaches. Though development and analysis efforts spanned over four years and presented various integration challenges it provided an example of successful collaboration with our International Partners.

Perez, Miguel Fernando↗