SEARCH · Engineering Papers

Results for “Flight safety”

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 811 records · Page 45

All sources NASA NTRS DOE OSTI

NASA NTRS2017

Prediction of Cognitive States During Flight Simulation Using Multimodal Psychophysiological Sensing

The Commercial Aviation Safety Team found the majority of recent international commercial aviation accidents attributable to loss of control inflight involved flight crew loss of airplane state awareness (ASA), and distraction was involved in all of them. Research on attention-related human performance limiting states (AHPLS) such as channelized attention, diverted attention, startle/surprise, and confirmation bias, has been recommended in a Safety Enhancement (SE) entitled "Training for Attention Management." To accomplish the detection of such cognitive and psychophysiological states, a broad suite of sensors was implemented to simultaneously measure their physiological markers during a high fidelity flight simulation human subject study. Twenty-four pilot participants were asked to wear the sensors while they performed benchmark tasks and motion-based flight scenarios designed to induce AHPLS. Pattern classification was employed to predict the occurrence of AHPLS during flight simulation also designed to induce those states. Classifier training data were collected during performance of the benchmark tasks. Multimodal classification was performed, using pre-processed electroencephalography, galvanic skin response, electrocardiogram, and respiration signals as input features. A combination of one, some or all modalities were used. Extreme gradient boosting, random forest and two support vector machine classifiers were implemented. The best accuracy for each modality-classifier combination is reported. Results using a select set of features and using the full set of available features are presented. Further, results are presented for training one classifier with the combined features and for training multiple classifiers with features from each modality separately. Using the select set of features and combined training, multistate prediction accuracy averaged 0.64 +/- 0.14 across thirteen participants and was significantly higher than that for the separate training case. These results support the goal of demonstrating simultaneous real-time classification of multiple states using multiple sensing modalities in high fidelity flight simulators. This detection is intended to support and inform training methods under development to mitigate the loss of ASA and thus reduce accidents and incidents.

Harrivel, Angela R.↗

NASA NTRSDate not supplied

Independent Verification and Validation for Artemis I Ascent Integrated Flight Performance Simulation

The NASA Engineering and Safety Center (NESC) has performed independent model development to support cross-model verification for the Space Launch System (SLS) Program since 2012 which culminated, for Artemis I, in a postflight reconciliation analysis of the Artemis I ascent trajectory (validation). This post-flight analysis was completed by both the NESC and the SLS Program. Upon successful completion of the Artemis I mission, multiple preflight simulations of the nominal ascent trajectory were updated with Day of Launch (DOL) conditions and simulated results were compared to reconstructed flight data derived from telemetry measurements. Dispersed trajectories were also produced using a combination of DOL conditions and preflight uncertainties, which ideally should bound the Artemis I flight data. Finally, multibody dynamics were simulated for some of the separation events to support clearance analyses. This paper focuses on validating and understanding the accuracy of the models by comparing simulated results against the Artemis I flight data. In addition, discrepancies uncovered between simulations led to opportunities to investigate areas for potential model improvement to refine preflight simulations for future Artemis missions. Included in this paper is background on the flight performance simulation tools, the postflight analysis approach, and a comparison of simulation results against the Artemis I flight data. Simulated results were found to generally be in close agreement with each other and the Artemis I flight data.

Jacob Fleck↗

NASA NTRS2016

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↗

NASA NTRS2005

Taking the Risk Out of Risk Assessment

The ability to understand risks and have the right strategies in place when risky events occur is essential in the workplace. More and more organizations are being confronted with concerns over how to measure their risks or what kind of risks they can take when certain events transpire that could have a negative impact. NASA is one organization that faces these challenges on a daily basis, as effective risk management is critical to the success of its missions especially the Space Shuttle missions. On July 29, 1996, former NASA Administrator Daniel Goldin charged NASA s Office of Safety and Mission Assurance with developing a probabilistic risk assessment (PRA) tool to support decisions on the funding of Space Shuttle upgrades. When issuing the directive, Goldin said, "Since I came to NASA [in 1992], we've spent billions of dollars on Shuttle upgrades without knowing how much they improve safety. I want a tool to help base upgrade decisions on risk." Work on the PRA tool began immediately. The resulting prototype, the Quantitative Risk Assessment System (QRAS) Version 1.0, was jointly developed by NASA s Marshall Space Flight Center, its Office of Safety and Mission Assurance, and researchers at the University of Maryland. QRAS software automatically expands the reliability logic models of systems to evaluate the probability of highly detrimental outcomes occurring in complex systems that are subject to potential accident scenarios. Even in its earliest forms, QRAS was used to begin PRA modeling of the Space Shuttle. In parallel, the development of QRAS continued, with the goal of making it a world-class tool, one that was especially suited to NASA s unique needs. From the beginning, an important conceptual goal in the development of QRAS was for it to help bridge the gap between the professional risk analyst and the design engineer. In the past, only the professional risk analyst could perform, modify, use, and perhaps even adequately understand PRA. NASA wanted to change this by developing a PRA tool that would be friendlier, more understandable, and more useful to the broader engineering community. This concept ultimately led to the look, feel, and functionality that QRAS has today.

Source record↗

NASA NTRS2014

Spot: A Programming Language for Verified Flight Software

The C programming language is widely used for programming space flight software and other safety-critical real time systems. C, however, is far from ideal for this purpose: as is well known, it is both low-level and unsafe. This paper describes Spot, a language derived from C for programming space flight systems. Spot aims to maintain compatibility with existing C code while improving the language and supporting verification with the SPIN model checker. The major features of Spot include actor-based concurrency, distributed state with message passing and transactional updates, and annotations for testing and verification. Spot also supports domain-specific annotations for managing spacecraft state, e.g., communicating telemetry information to the ground. We describe the motivation and design rationale for Spot, give an overview of the design, provide examples of Spot's capabilities, and discuss the current status of the implementation.

validation↗

NASA NTRSDate not supplied

System Safety Analysis of Complex NASA Systems with Model-Based Engineering

The emergence of model-based engineering is transforming design and analysis methodologies [5]. A recognized benefit of model-based engineering is the existence of a “single source of truth” about the system that becomes the authoritative source of data and information for designers, analysts, and developers. This promotes consistency and efficiency as the design emerges and can be used to further optimize the design. Integrating System Safety Engineers to the “single source of truth” will ensure that the outputs of their assessments and analyses are relevant to the design as it evolves. Use of an integrated system model enables near immediate evaluation of a design change as well as development of operational processes for risk assessment and communication. Such models can enable efficient and timely analysis of system hazards (e.g., hazard fault tree analysis and procedure simulations) and produce complete, accurate, and more consistent products (e.g., hazard reports and safety requirement evaluations). Therefore, an agency-sponsored team at Goddard Space Flight Center (GSFC) recently completed a System Safety Study of modeling and testing capabilities as part of a Model-Based Safety and Mission Assurance Initiative (MBSMAI). Using an existing model developed for reliability analyses [1], GSFC modeling and system safety experts performed system safety analysis/modeling and produced safety products. The team evaluated model-based feasibility to support System Safety Engineering, developed safety analysis modeling processes, and identified tool capability advancement/development needs. These study results indicate model-based engineering is valid and useable for System

NASA↗

NASA NTRSDate not supplied

System Safety Analysis of Complex NASA Systems with Model Based Engineering

Model Based Engineering↗

NASA NTRSDate not supplied

System Safety Analysis of Complex NASA Systems with Model-Based Engineering (REV B)

The emergence of model-based engineering is transforming design and analysis methodologies. A recognized benefit of model-based engineering is the existence of a “single source of truth” about the system that becomes the authoritative source of data and information for designers, analysts, and developers. This promotes consistency and efficiency as the design emerges and can be used to further optimize the design. Integrating System Safety Engineers to the “single source of truth” will ensure that the outputs of their assessments and analyses are relevant to the design as it evolves. Use of an integrated system model enables near immediate evaluation of a design change as well as development of operational processes for risk assessment and communication. Such models can enable efficient and timely analysis of system hazards (e.g., hazard fault tree analysis and procedure simulations) and produce complete, accurate, and more consistent products (e.g., hazard reports and safety requirement evaluations). Therefore, an agency-sponsored team at Goddard Space Flight Center (GSFC) recently completed a System Safety Study of modeling and testing capabilities as part of a Model-Based Safety and Mission Assurance Initiative (MBSMAI). Using an existing model developed for reliability analyses, GSFC modeling and system safety experts performed system safety analysis/modeling and produced safety products. The team evaluated model-based feasibility to support System Safety Engineering, developed safety analysis modeling processes, and identified tool capability advancement/development needs. These study results indicate model-based engineering is valid and useable for System Safety Engineering for NASA if adequate modeling processes and environment are established.

NASA↗

NASA NTRS1985

SSME digital control design characteristics

To protect against a latent programming error (software fault) existing in an untried branch combination that would render the space shuttle out of control in a critical flight phase, the Backup Flight System (BFS) was chartered to provide a safety alternative. The BFS is designed to operate in critical flight phases (ascent and descent) by monitoring the activities of the space shuttle flight subsystems that are under control of the primary flight software (PFS) (e.g., navigation, crew interface, propulsion), then, upon manual command by the flightcrew, to assume control of the space shuttle and deliver it to a noncritical flight condition (safe orbit or touchdown). The problems associated with the selection of the PFS/BFS system architecture, the internal BFS architecture, the fault tolerant software mechanisms, and the long term BFS utility are discussed.

Mitchell, W. T.↗

NASA NTRS2010

The NASA Langley Research Center's Unmanned Aerial System Surrogate Research Aircraft

Research is needed to determine what procedures, aircraft sensors and other systems will be required to allow Unmanned Aerial Systems (UAS) to safely operate with manned aircraft in the National Airspace System (NAS). The NASA Langley Research Center has transformed a Cirrus Design SR22 general aviation (GA) aircraft into a UAS Surrogate research aircraft to serve as a platform for UAS systems research, development, flight testing and evaluation. The aircraft is manned with a Safety Pilot and systems operator that allows for flight operations almost anywhere in the NAS without the need for a Federal Aviation Administration (FAA) Certificate of Authorization (COA). The UAS Surrogate can be controlled from a modular, transportable ground station like a true UAS. The UAS Surrogate is able to file and fly in the NAS with normal traffic and is a better platform for real world UAS research and development than existing vehicles flying in restricted ranges or other sterilized airspace. The Cirrus Design SR22 aircraft is a small, singleengine, four-place, composite-construction aircraft that NASA Langley acquired to support NASA flight-research programs like the Small Aircraft Transportation System (SATS) Project. Systems were installed to support flight test research and data gathering. These systems include: separate research power; multi-function flat-panel displays; research computers; research air data and inertial state sensors; video recording; data acquisition; data-link; S-band video and data telemetry; Common Airborne Instrumentation System (CAIS); Automatic Dependent Surveillance-Broadcast (ADS-B); instrumented surfaces and controls; and a systems operator work station. The transformation of the SR22 to a UAS Surrogate was accomplished in phases. The first phase was to modify the existing autopilot to accept external commands from a research computer that was connected by redundant data-link radios to a ground control station. An electro-mechanical auto-throttle was added in the next phase to provide ground station control of airspeed. Additional phases are in progress to add waypoint navigation and long range satellite voice and data communications. Potential areas for UAS Surrogate research include the development, flight test and evaluation of sensors to aid in the process of air traffic detect-sense-and-avoid. These sensors could be evaluated in real-time and compared with onboard human evaluation pilots. This paper describes the systems and design considerations that were incorporated in the development of the UAS Surrogate along with details of development problems encountered and the corresponding solutions.

Howell, Charles T., III↗

NASA NTRS1993

Structural Safety of a Hubble Space Telescope Science

For a flight hardware system to be launched and/or retrieved by the Space Shuttle, the development of its structures must address both personnel safety and safety of the mission. Safety of personnel and the Shuttle has been a paramount concern for the National Space Transportation System (NSTS) since the first Shuttle flight in 1980.

fracture control Wide-Field/Planetary Camera (WF/P↗

NASA NTRS1992

Safety issues of manipulator systems under computer control

An overview of the development test flight (DTF-1) mission is presented, and the system design, safety requirements, and safety features are described. The lessons that were learned during the design and early development stages are also presented. The DTF-1 mission objectives are to evaluate: the overall man-machine performance in zero G, Flight Telerobotic Service manipulator design, and workstation design, including handcontrollers and displays. The payload bay and aft flight deck elements, and computer control of the DTF-1 are described. Recommendations for developing and implementing a safety system are presented, and some design alternatives for the next space-qualified telerobotic system are suggested.

Andary, James F.↗

NASA NTRS2017

Current Safety Nets Within the U.S. National Airspace System

There are over 70,000 flights managed per day in the National Airspace System, with approximately 7,000 aircraft in the air over the United States at any given time. Operators of each of these flights would prefer to fly a user-defined “4D” trajectory (4DT), which includes arrival and departure times; preferred gates and runways at the airport; efficient, wind-optimal routes for departure, cruise and arrival phase of flight; and fuel efficient altitude profiles. To demonstrate the magnitude of this achievement a single flight from Los Angeles to Baltimore, accesses over 35 shared or “constrained” resources that are managed by roughly 30 air traffic controllers (at towers, approach control and en route sectors); along with traffic managers at 12 facilities, using over 22 different, independent automation system (including TBFM, ERAM, STARS, ASDE-X, FSM, TSD, GPWS, TCAS, etc.). In addition, dispatchers, ramp controllers and others utilize even more systems to manage each flight’s access to operator-managed resources. Flying an ideal 4DT requires successful coordination of all flight constraints among all flights, facilities, operators, pilots and controllers. Additionally, when conditions in the NAS change, the trajectories of one or more aircraft may need to be revised to avoid loss of flight efficiency, predictability, separation or system throughput. The Aviation Safety Network has released the 2016 airliner accident statistics showing a very low total of 19 fatal airliner accidents, resulting in 325 fatalities1. Despite several high profile accidents, the year 2016 turned out to be a very safe year for commercial aviation, Aviation Safety Network data show. Over the year 2016 the Aviation Safety Network recorded a total of 19 fatal airliner accidents [1], resulting in 325 fatalities. This makes 2016 the second safest year ever, both by number of fatal accidents as well as in terms of fatalities. In 2015 ASN recorded 16 accidents while in 2013 a total of 265 lives were lost. How can we keep it that way and not upset the apple cart by premature insertion of innovative technologies, functions, and procedures? In aviation, safety nets function as the last system defense against incidents and accidents. Current ground-based and airborne safety nets are well established and development to make them more efficient and reliable continues. Additionally, future air traffic control safety nets may emerge from new operational concepts.

Smith, Brian E.↗

NASA NTRS2011

Flight Simulation Model Exchange: Appendices - Volume 2

The NASA Engineering and Safety Center Review Board sponsored an assessment of the draft Standard, Flight Dynamics Model Exchange Standard, BSR/ANSI-S-119-201x (S-119) that was conducted by simulation and guidance, navigation, and control engineers from several NASA Centers. The assessment team reviewed the conventions and formats spelled out in the draft Standard and the actual implementation of two example aerodynamic models (a subsonic F-16 and the HL-20 lifting body) encoded in the Extensible Markup Language grammar. During the implementation, the team kept records of lessons learned and provided feedback to the American Institute of Aeronautics and Astronautics Modeling and Simulation Technical Committee representative. This document contains the appendices to the main report.

Murri, Daniel G.↗

NASA NTRS2015

Orion Launch Abort System Performance on Exploration Flight Test 1

This paper will present an overview of the flight test objectives and performance of the Orion Launch Abort System during Exploration Flight Test-1. Exploration Flight Test-1, the first flight test of the Orion spacecraft, was managed and led by the Orion prime contractor, Lockheed Martin, and launched atop a United Launch Alliance Delta IV Heavy rocket. This flight test was a two-orbit, high-apogee, high-energy entry, low-inclination test mission used to validate and test systems critical to crew safety. This test included the first flight test of the Launch Abort System preforming Orion nominal flight mission critical objectives. NASA is currently designing and testing the Orion Multi-Purpose Crew Vehicle (MPCV). Orion will serve as NASA's new exploration vehicle to carry astronauts to deep space destinations and safely return them to earth. The Orion spacecraft is composed of four main elements: the Launch Abort System, the Crew Module, the Service Module, and the Spacecraft Adapter (Fig. 1). The Launch Abort System (LAS) provides two functions; during nominal launches, the LAS provides protection for the Crew Module from atmospheric loads and heating during first stage flight and during emergencies provides a reliable abort capability for aborts that occur within the atmosphere. The Orion Launch Abort System (LAS) consists of an Abort Motor to provide the abort separation from the Launch Vehicle, an Attitude Control Motor to provide attitude and rate control, and a Jettison Motor for crew module to LAS separation (Fig. 2). The jettison motor is used during a nominal launch to separate the LAS from the Launch Vehicle (LV) early in the flight of the second stage when it is no longer needed for aborts and at the end of an LAS abort sequence to enable deployment of the crew module's Landing Recovery System. The LAS also provides a Boost Protective Cover fairing that shields the crew module from debris and the aero-thermal environment during ascent. Although the Orion Program has tested a number of the critical systems of the Orion spacecraft on the ground, the launch environment cannot be replicated completely on Earth. A number of flight tests have been conducted and are planned to demonstrate the performance and enable certification of the Orion Spacecraft. Exploration Flight Test 1, the first flight test of the Orion spacecraft, was successfully flown on December 5, 2014 from Cape Canaveral Air Force Station's Space Launch Complex 37. Orion's first flight was a two-orbit, high-apogee, high-energy entry, low-inclination test mission used to validate and test systems critical to crew safety, such as heat shield performance, separation events, avionics and software performance, attitude control and guidance, parachute deployment and recovery operations. One of the key separation events tested during this flight was the nominal jettison of the LAS. Data from this flight will be used to verify the function of the jettison motor to separate the Launch Abort System from the crew module so it can continue on with the mission. The LAS nominal jettison event on Exploration Flight Test 1 occurred at six minutes and twenty seconds after liftoff (See Fig. 3). The abort motor and attitude control motors were inert for Exploration Flight Test 1, since the mission did not require abort capabilities. A suite of developmental flight instrumentation was included on the flight test to provide data on spacecraft subsystems and separation events. This paper will focus on the flight test objectives and performance of the LAS during ascent and nominal jettison. Selected LAS subsystem flight test data will be presented and discussed in the paper. Exploration Flight Test -1 will provide critical data that will enable engineering to improve Orion's design and reduce risk for the astronauts it will protect as NASA continues to move forward on its human journey to Mars. The lessons learned from Exploration Flight Test 1 and the other Flight Test Vehicles will certainly contribute to the vehicle architecture of a human-rated space launch vehicle.

McCauley, R.↗

NASA NTRS1991

Galileo Attitude Determination: Experiences with a Rotating Star Scanner

The Galileo experience with a rotating star scanner is discussed in terms of problems encountered in flight, solutions implemented, and lessons learned. An overview of the Galileo project and the attitude and articulation control subsystem is given and the star scanner hardware and relevant software algorithms are detailed. The star scanner is the sole source of inertial attitude reference for this spacecraft. Problem symptoms observed in flight are discussed in terms of effects on spacecraft performance and safety. Sources of thse problems include contributions from flight software idiosyncrasies and inadequate validation of the ground procedures used to identify target stars for use by the autonomous on-board star identification algorithm. Problem fixes (some already implemented and some only proposed) are discussed. A general conclusion is drawn regarding the inherent difficulty of performing simulation tests to validate algorithms which are highly sensitive to external inputs of statistically 'rare' events.

Merken, L.↗

NASA NTRS2008

Volume Averaged Height Integrated Radar Reflectivity (VAHIRR) Cost-Benefit Analysis

Lightning Launch Commit Criteria (LLCC) are designed to prevent space launch vehicles from flight through environments conducive to natural or triggered lightning and are used for all U.S. government and commercial launches at government and civilian ranges. They are maintained by a committee known as the NASA/USAF Lightning Advisory Panel (LAP). The previous LLCC for anvil cloud, meant to avoid triggered lightning, have been shown to be overly restrictive. Some of these rules have had such high safety margins that they prohibited flight under conditions that are now thought to be safe 90% of the time, leading to costly launch delays and scrubs. The LLCC for anvil clouds was upgraded in the summer of 2005 to incorporate results from the Airborne Field Mill (ABFM) experiment at the Eastern Range (ER). Numerous combinations of parameters were considered to develop the best correlation of operational weather observations to in-cloud electric fields capable of rocket triggered lightning in anvil clouds. The Volume Averaged Height Integrated Radar Reflectivity (VAHIRR) was the best metric found. Dr. Harry Koons of Aerospace Corporation conducted a risk analysis of the VAHIRR product. The results indicated that the LLCC based on the VAHIRR product would pose a negligible risk of flying through hazardous electric fields. Based on these findings, the Kennedy Space Center Weather Office is considering seeking funding for development of an automated VAHIRR algorithm for the new ER 45th Weather Squadron (45 WS) RadTec 431250 weather radar and Weather Surveillance Radar-1988 Doppler (WSR-88D) radars. Before developing an automated algorithm, the Applied Meteorology Unit (AMU) was tasked to determine the frequency with which VAHIRR would have allowed a launch to safely proceed during weather conditions otherwise deemed "red" by the Launch Weather Officer. To do this, the AMU manually calculated VAHIRR values based on candidate cases from past launches with known anvil cloud LLCC violations. An automated algorithm may be developed if the analyses from past launches show VAHIRR would have provided a significant cost benefit by allowing a launch to proceed. The 45 WS at the ER and 30th Weather Squadron (30 WS) at the Western Range provided the AMU with launch weather summaries from past launches that were impacted by LLCC. The 45 WS provided summaries from 14 launch attempts and the 30 WS fkom 5. The launch attempts occurred between December 2001 and June 2007. These summaries helped the AMU determine when the LLCC were "red" due to anvil cloud. The AMU collected WSR-88D radar reflectivity, cloud-to-ground lightning strikes, soundings and satellite imagery. The AMU used step-by-step instructions for calculating VAHIRR manually as provided by the 45 WS. These instructions were used for all of the candidate cases when anvil cloud caused an LLCC violation identified in the launch weather summaries. The AMU evaluated several software programs capable of visualizing radar data so that VAHIRR could be calculated and chose GR2Analyst from Gibson Ridge Software, LLC. Data availability and lack of detail from some launch weather summaries permitted analysis of six launch attempts from the ER and none from the WR. The AMU did not take into account whether or not other weather LCC violations were occurring at the same time as the anvil cloud LLCC since the goal of this task was to determine how often VAHIRR provided relief to the anvil cloud LLCC at any time during several previous launch attempts. Therefore, in the statistics presented in this report, it is possible that even though VAHIRR provided relief to the anvil cloud LLCC, other weather LCC could have been violated not permitting the launch to proceed. The results of this cost-benefit analysis indicated VAHIRR provided relief from the anvil cloud LLCC between about 15% and 18% of the time for varying 5-minute time periods based on summaries fkom six launch attempts and would have allowed launch to proceed that were otherwise "NO GO" due to the anvil cloud LLCC if the T-0 time occurred during the anvil cloud LLCC violations.

Bauman, William H., III↗

NASA NTRS2009

Shuttle Ground Support Equipment (GSE) T-0 Umbilical to Space Shuttle Program (SSP) Flight Elements Consultation

The NASA Engineering and Safety Center (NESC) was tasked with assessing the validity of an alternate opinion that surfaced during the investigation of recurrent failures at the Space Shuttle T-0 umbilical interface. The most visible problem occurred during the Space Transportation System (STS)-112 launch when pyrotechnics used to separate Solid Rocket Booster (SRB) Hold-Down Post (HDP) frangible nuts failed to fire. Subsequent investigations recommended several improvements to the Ground Support Equipment (GSE) and processing changes were implemented, including replacement of ground-half cables and connectors between flights, along with wiring modifications to make critical circuits quad-redundant across the interface. The alternate opinions maintained that insufficient data existed to exonerate the design, that additional data needed to be gathered under launch conditions, and that the interface should be further modified to ensure additional margin existed to preclude failure. The results of the assessment are contained in this report.

Wilson, Timmy R.↗