Search NASA⌕ Search

SEARCH · Search NASA

Results for “COUNTDOWN”

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.

264 records · Page 15

Use of DES Modeling for Determining Launch Availability for SLS

The National Aeronautics and Space Administration (NASA) is developing new capabilities for human and scientific exploration beyond Earth's orbit. This effort includes the Space Shuttle derived Space Launch System (SLS), the Multi-Purpose Crew Vehicle (MPCV) "Orion", and the Ground Systems Development and Operations (GSDO). There are several requirements and Technical Performance Measures (TPMs) that have been levied by the Exploration Systems Development (ESD) upon the SLS, MPCV, and GSDO Programs including an integrated Launch Availability (LA) TPM. The LA TPM is used to drive into the SLS, Orion and GSDO designs a high confidence of successfully launching exploration missions that have narrow Earth departure windows. The LA TPM takes into consideration the reliability of the overall system (SLS, Orion and GSDO), natural environments, likelihood of a failure, and the time required to recover from an anomaly. A challenge with the LA TPM is the interrelationships between SLS, Orion, GSDO and the natural environments during launch countdown and launch delays that makes it impossible to develop an analytical solution for calculating the integrated launch probability. This paper provides an overview of how Discrete Event Simulation (DES) modeling was used to develop the LA TPM, how it was allocated down to the individual programs, and how the LA analysis is being used to inform and drive the SLS, Orion, and GSDO designs to ensure adequate launch availability for future human exploration.

Watson, Mike↗

Use of DES Modeling for Determining Launch Availability for SLS

The National Aeronautics and Space Administration (NASA) is developing new capabilities for human and scientific exploration beyond Earth's orbit. This effort includes the Space Shuttle derived Space Launch System (SLS), the Orion Multi-Purpose Crew Vehicle (MPCV), and the Ground Systems Development and Operations (GSDO). There are several requirements and Technical Performance Measures (TPMs) that have been levied by the Exploration Systems Development (ESD) upon the SLS, Orion, and GSDO Programs including an integrated Launch Availability (LA) TPM. The LA TPM is used to drive into the SLS, Orion and GSDO designs a high confidence of successfully launching exploration missions that have narrow Earth departure windows. The LA TPM takes into consideration the reliability of the overall system (SLS, Orion and GSDO), natural environments, likelihood of a failure, and the time required to recover from an anomaly. A challenge with the LA TPM is the interrelationships between SLS, Orion, GSDO and the natural environments during launch countdown and launch delays that makes it impossible to develop an analytical solution for calculating the integrated launch probability. This paper provides an overview of how Discrete Event Simulation (DES) modeling was used to develop the LA TPM, how it was allocated down to the individual programs, and how the LA analysis is being used to inform and drive the SLS, Orion, and GSDO designs to ensure adequate launch availability for future human exploration.

Staton, Eric↗

Arrival Metering Precision Study

This paper describes the background, method and results of the Arrival Metering Precision Study (AMPS) conducted in the Airspace Operations Laboratory at NASA Ames Research Center in May 2014. The simulation study measured delivery accuracy, flight efficiency, controller workload, and acceptability of time-based metering operations to a meter fix at the terminal area boundary for different resolution levels of metering delay times displayed to the air traffic controllers and different levels of airspeed information made available to the Time-Based Flow Management (TBFM) system computing the delay. The results show that the resolution of the delay countdown timer (DCT) on the controllers display has a significant impact on the delivery accuracy at the meter fix. Using the 10 seconds rounded and 1 minute rounded DCT resolutions resulted in more accurate delivery than 1 minute truncated and were preferred by the controllers. Using the speeds the controllers entered into the fourth line of the data tag to update the delay computation in TBFM in high and low altitude sectors increased air traffic control efficiency and reduced fuel burn for arriving aircraft during time based metering.

human/systems↗

ADDJUST-A View of the First 25 Years

Various technologies and innovative launch operations were developed during the 50 years of the Centaur upper stage—the first launch vehicle to use high performing liquid hydrogen fuel. One innovation was “ADDJUST”, which enabled the successful negotiation of upper level winds measured only hours before launch. Initial causes for its creation, development, and operation during countdown are detailed. Problem definition, wind measuring/monitoring process, pitch and yaw steering coefficient generation, loads analysis, angle of attack, major risks/concerns, and anecdotal recollections are provided. Launch availability improved from as low as 55 to 95 percent due to ADDJUST, which is still in use.

Upper level winds↗

Safety Characteristics in System Application of Software for Human Rated Exploration Missions for the 8th IAASS Conference

NASA and its industry and international partners are embarking on a bold and inspiring development effort to design and build an exploration class space system. The space system is made up of the Orion system, the Space Launch System (SLS) and the Ground Systems Development and Operations (GSDO) system. All are highly coupled together and dependent on each other for the combined safety of the space system. A key area of system safety focus needs to be in the ground and flight application software system (GFAS). In the development, certification and operations of GFAS, there are a series of safety characteristics that define the approach to ensure mission success. This paper will explore and examine the safety characteristics of the GFAS development. The GFAS system integrates the flight software packages of the Orion and SLS with the ground systems and launch countdown sequencers through the 'agile' software development process. A unique approach is needed to develop the GFAS project capabilities within this agile process. NASA has defined the software development process through a set of standards. The standards were written during the infancy of the so-called industry 'agile development' movement and must be tailored to adapt to the highly integrated environment of human exploration systems. Safety of the space systems and the eventual crew on board is paramount during the preparation of the exploration flight systems. A series of software safety characteristics have been incorporated into the development and certification efforts to ensure readiness for use and compatibility with the space systems. Three underlining factors in the exploration architecture require the GFAS system to be unique in its approach to ensure safety for the space systems, both the flight as well as the ground systems. The first are the missions themselves, which are exploration in nature, and go far beyond the comfort of low Earth orbit operations. The second is the current exploration system will launch only one mission per year even less during its developmental phases. Finally, the third is the partnered approach through the use of many different prime contractors, including commercial and international partners, to design and build the exploration systems. These three factors make the challenges to meet the mission preparations and the safety expectations extremely difficult to implement. As NASA leads a team of partners in the exploration beyond earth's influence, it is a safety imperative that the application software used to test, checkout, prepare and launch the exploration systems put safety of the hardware and mission first. Software safety characteristics are built into the design and development process to enable the human rated systems to begin their missions safely and successfully. Exploration missions beyond Earth are inherently risky, however, with solid safety approaches in both hardware and software, the boldness of these missions can be realized for all on the home planet.

capability↗

In the Hot Seat: STS-115 Lightning Strike Stand Down Debate - NASA Case Study

There is no way the PIC's could have seen any current' was the gist of Mike Griffin's assessment. Griffin was the NASA Administrator at the time. The buck stopped at his desk. Holding a napkin out to Pat Lampton, Griffin showed Lampton the calculations he'd made over dinner that predicted that the Pyrotechnic Initiator Controllers (PIC's) at the base of the Space Shuttle Solid Rocket Boosters (SRBs) were fine. A lightning strike the day before, the worst ever experienced with a Space Shuttle on the launch pad, caused a halt to the launch count down as technicians, engineers, and managers scrambled identify any damage to the launch system. SRB technicians and engineers assessed the data against their Lightning Strike Re-Test Requirements, determining that all but one of the requirements could be checked if they resumed the countdown. For the one remaining requirement, testing the integrity of the PIC's would require 96 hours to set up, test, and reassemble. The engineers were convinced that there was no way to do calculations to show the PIC's were okay. The only option was to stand down. It was SRB Deputy Project Manager (PM) Pat Lampton's responsibility to decide what the SRB project position needed to be to certify that their hardware was safe to fly. He had to communicate that decision to the Mission Management Team (MMT) as a Go or No Go position to resume the count down. If the answer was Go they could still meet a delayed, but acceptable launch schedule. If the answer was No Go, rescheduling the launch would be a grueling shuffling of hardware, personnel, and mission timelines to accommodate Russian missions to the Space Station, supplies for the launch, and personnel manning launch operations. On top of that, Hurricane Ernesto was spinning off the coast of Florida, threatening the need for the Shuttle to roll back to the hangar if they waited too long.

Kummer, Lizette↗

Work Experience Report

The NASA Platform for Autonomous Systems (NPAS) toolkit is currently being used at the NASA John C. Stennis Space Center (SSC) to develop the INSIGHT program, which will autonomously monitor and control the Nitrogen System of the High Pressure Gas Facility (HPGF) on site. The INSIGHT program is in need of generic timing capabilities in order to perform timing based actions such as pump usage timing and sequence step timing. The purpose of this project was to develop a timing module that could fulfill these requirements and be adaptable for expanded use in the future. The code was written in Gensym G2 software platform, the same as INSIGHT, and was written generically to ensure compatibility with any G2 program. Currently, the module has two timing capabilities, a stopwatch function and a countdown function. Although the module has gone through some functionality testing, actual integration of the module into NPAS and the INSIGHT program is contingent on the module passing later checks.

Guo, Daniel↗

Analyses of Kennedy Space Center Tropospheric Doppler Radar Wind Profiler Data for Space Launch System Program Certification

This paper documents the methodology and results of analyses used to certify the Kennedy Space Center (KSC) Tropospheric Doppler Radar Wind Profiler (TDRWP) as input to launch commit evaluations for the National Aeronautics and Space Administration’s (NASA) Space Launch System Program (SLSP). These analyses, and the requirements that they address, were designed by the Marshall Space Flight Center Natural Environments Branch (MSFC NE) to certify that the TDRWP provides data of sufficient accuracy and resolution for SLSP, and that the instrument provides enough reliability to support Day-of- Launch Initialization Loads Update (DOLILU) operations. On day-of-launch (DOL), space launch vehicle operators have used data from wind profilers to reverse a previous GO call in prelaunch loads and trajectory assessments due to the profiler’s capability to quickly identify changes in the wind profile within a rapidly changing wind environment. Certification of the TDRWP would allow SLSP to use DOL wind data generated by the TDRWP to design the vehicle trajectory and to verify trajectory and load constraints during the countdown for launch commit decision.

Barbre, Robert E., Jr.↗

Artemis I Orion IMU Flight Performance

The Orion flight software’s parity algorithm runs onboard to verify all three OIMUs (Orion Inertial Measurement Units) are sensing relatively uniform rate and acceleration and to quickly identify any unit which is in significant disagreement with the other two units. During the Artemis-I Wet Dress Rehearsal tests and Launch Countdowns, one of the three OIMUs regularly reported an anomalous parity signature for a brief period of time during sensor warm up. This paper will review this anomalous performance on the pad and review flight data with the intent to supplement the findings of the initial root cause investigation. Outside of this start up behavior, initial investigation into Artemis I flight data did not reveal any behavior of the OIMUs outside of preflight expectations. Flight data from any significant parity events and relevant IMU calibrations will be presented. A brief discussion of impacts to future Artemis mission operations strategy will be provided.

Robert Earl↗

Artemis I Is the First NASA Mission to Use Wi-Fi® in Lunar Orbit

During the countdown procedure for the Artemis I launch, the flight control team at NASA’s Johnson Space Center in Houston activated a set of cameras looking back at the vehicle from the wing-tips of the solar arrays. Throughout the flight, the team used photos from these cameras to survey and assess the condition of the vehicle, monitor for micrometeorite damage, and maintain situational awareness. The ground control team was even able to watch live video as the solar array wings unfolded. The cameras continued to store imagery to internal memory as well as send photos over Wi-Fi® even as the vehicle lost communication with Earth as it flew behind the moon. Artemis I is the first NASA mission to use WiFi in lunar orbit.

Wi-Fi↗

Evaluating Liftoff Debris for NASA’s Space Launch System (SLS) Prior to the Artemis I Launch

The SLS Artemis I launch vehicle is the first of several planned Artemis launch vehicles, with a number of design differences from earlier NASA missions that incur liftoff debris risk to the mission. As a test vehicle, the Artemis I hardware also endured environments and tests not planned for future missions, which led to several additional factors contributing to an evolving liftoff debris risk to the SLS vehicle. This paper will summarize these risk factors and address the processes used to evaluate and communicate the risks to support a successful Artemis I launch. It will discuss how the evolving risks that were quantified and evaluated by a Cross-Program team of debris Subject Matter Experts to mitigate liftoff debris hazards and communicate updated risk to the SLS vehicle. This process was performed through the inaugural use of an SLS debris day-of-launch (DOL) standard operating procedure that will be used for subsequent Artemis missions. This paper addresses the risk of liftoff debris, debris released by the vehicle or from the launch pad during liftoff through vehicle tower clear. Expected liftoff debris is well understood from previous NASA programs’ experience and from tests of materials, processes and functions that are known to release liftoff debris. These expected sources were assessed and cleared well ahead of launch day. However, given the ever-changing schedules and environments, processes were in place to evaluate any additional potential liftoff debris risks identified during launch countdown. Although many of the Artemis vehicle hardware components are similar to those on the NASA Shuttle Program, there are important differences in the architecture of the Artemis I vehicle which require new assessments of liftoff debris risk for the Artemis missions. The more favorable Artemis crew module location and surfaces are far less vulnerable to debris impacts; however, the longer vehicle can result in higher liftoff debris impact energies to those components on the aft end of the vehicle. Additionally, the positional change of the RS-25 liquid engines to nearer the Booster nozzle exit plane along with the change in Booster throat plug design is a disadvantage to the overall liftoff debris risk which resulted in additional test and analysis efforts for evaluating the integrated vehicle debris risk. In spite of the comprehensive tests and analyses of Artemis I expected liftoff debris, a number of additional tests/processes were completed prior to the Artemis I mission that were required to support a complete understanding of a new launch vehicle, but increased the risk of releasing liftoff debris. The hardware endured several additional cryogenic loading cycles, including the Green Run tests at Stennis Space Center, Wet Dress Rehearsals at Kennedy Space Center, and multiple launch attempts. Each of these cycles induced stresses in the thermal protection system (TPS) materials, increasing the risk of damage to and release of the TPS. Additionally, induced and weather environmental factors that could increase the likelihood of debris release were significant. Vibrations and stresses in the TPS were induced by a required roll-back to the Vehicle Assembly Building before Hurricane Ian to protect the vehicle from damage by high winds. Wind damage and potential internal stresses to several outer mold line materials on the integrated SLS vehicle and mobile launcher were caused by weathering Hurricane Nicole at Pad 39B the week before launch. A thorough imagery scan of the vehicle was performed after each event and the damage observed was repaired, removed, or assessed and the risk to the mission evaluated. Mitigation of debris risk can occur by tests and analyses to show debris impacted components as damage tolerant, by new/improved processes for prevention of debris availability, or redesign. Risk mitigation processes for Artemis I-specific liftoff debris events and the development and use of the SLS debris day of launch (DOL) procedures that will be used for subsequent Artemis missions will be described.

Space Launch System↗

Evaluating Liftoff Debris for NASA’s Space Launch System (SLS) Prior to the Artemis I Launch

The SLS Artemis I launch vehicle is the first of several planned Artemis launch vehicles, with a number of design differences from earlier NASA missions that incur liftoff debris risk to the mission. As a test vehicle, the Artemis I hardware also endured environments and tests not planned for future missions, which led to several additional factors contributing to an evolving liftoff debris risk to the SLS vehicle. This paper will summarize these risk factors and address the processes used to evaluate and communicate the risks to support a successful Artemis I launch. It will discuss how the evolving risks that were quantified and evaluated by a Cross-Program team of debris Subject Matter Experts to mitigate liftoff debris hazards and communicate updated risk to the SLS vehicle. This process was performed through the inaugural use of an SLS debris day-of-launch (DOL) standard operating procedure that will be used for subsequent Artemis missions. This paper addresses the risk of liftoff debris, debris released by the vehicle or from the launch pad during liftoff through vehicle tower clear. Expected liftoff debris is well understood from previous NASA programs’ experience and from tests of materials, processes and functions that are known to release liftoff debris. These expected sources were assessed and cleared well ahead of launch day. However, given the ever-changing schedules and environments, processes were in place to evaluate any additional potential liftoff debris risks identified during launch countdown. Although many of the Artemis vehicle hardware components are similar to those on the NASA Shuttle Program, there are important differences in the architecture of the Artemis I vehicle which require new assessments of liftoff debris risk for the Artemis missions. The more favorable Artemis crew module location and surfaces are far less vulnerable to debris impacts; however, the longer vehicle can result in higher liftoff debris impact energies to those components on the aft end of the vehicle. Additionally, the positional change of the RS-25 liquid engines to nearer the Booster nozzle exit plane along with the change in Booster throat plug design is a disadvantage to the overall liftoff debris risk which resulted in additional test and analysis efforts for evaluating the integrated vehicle debris risk. In spite of the comprehensive tests and analyses of Artemis I expected liftoff debris, a number of additional tests/processes were completed prior to the Artemis I mission that were required to support a complete understanding of a new launch vehicle, but increased the risk of releasing liftoff debris. The hardware endured several additional cryogenic loading cycles, including the Green Run tests at Stennis Space Center, Wet Dress Rehearsals at Kennedy Space Center, and multiple launch attempts. Each of these cycles induced stresses in the thermal protection system (TPS) materials, increasing the risk of damage to and release of the TPS. Additionally, induced and weather environmental factors that could increase the likelihood of debris release were significant. Vibrations and stresses in the TPS were induced by a required roll-back to the Vehicle Assembly Building before Hurricane Ian to protect the vehicle from damage by high winds. Wind damage and potential internal stresses to several outer mold line materials on the integrated SLS vehicle and mobile launcher were caused by weathering Hurricane Nicole at Pad 39B the week before launch. A thorough imagery scan of the vehicle was performed after each event and the damage observed was repaired, removed, or assessed and the risk to the mission evaluated. Mitigation of debris risk can occur by tests and analyses to show debris impacted components as damage tolerant, by new/improved processes for prevention of debris availability, or redesign. Risk mitigation processes for Artemis I-specific liftoff debris events and the development and use of the SLS debris day of launch (DOL) procedures that will be used for subsequent Artemis missions will be described.

Space Launch System↗