SEARCH · Search NASA
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.
This paper provides an overview of the U.S. space nuclear power system launch approval process as defined by the two separate requirements of the National Environmental Policy Act (NEPA) and Presidential Directive/National Security Council Memorandum No. 25 (PD/NSC-25).
An interactive, menu driven computer program was written to streamline the orbit determination process during the critical launch support phase of a mission. Residing on a virtual memory minicomputer, this program retains the quantities in-core needed to obtain a least squares estimate of the spacecraft trajectory with interactive displays to assist in rapid radio metric data evaluation. Menu-driven displays allow real time filter and data strategy development. Graphical and tabular displays can be sent to a laser printer for analysis without exiting the program. Products generated by this program feed back to the main orbit determination program in order to further refine the estimate of the trajectory. The final estimate provides a spacecraft ephemeris which is transmitted to the mission control center and used for antenna pointing and frequency predict generation by the Deep Space Network. The development and implementation process of this program differs from that used for most other navigation software by allowing the users to check important operating features during development and have changes made as needed.
Eight urethane compounds were evaluated as possible replacement for the existing encapsulating compoounds for electrical cables for the Launch Support System at Kennedy Space Center (KSC). The existing encapsulating compound, PR-1535, contains the curative MOCA 4-4'-Methylene-BIS (2-chloroaniline), which is a suspect carcinogen and hence may be the subject of further restrictions of its use by the Occupational Safety and Health Administration (OSHA). The samples made in the configuration of cable joints and in the form of disks were evaluated for flammability and hypergolic compatibility. These also underwent accelerated weatherability tests that measured the residual hardness of the exposed samples. Three candidates and the existing compound passed the hardness test. Of these, only one candidate and the existing compound passed the flammability test. The thermal and hydrolytic stability (weatherability) of these samples was studied using thermogravimetric analysis (DSC) techniques. The TMA and DSC data correlated with the residual hardness data; whereas, the TGA data showed no correlation. A hypergolic compatibility test will be conducted on the compound V-356-HE80, which passed both the flammability and accelerated weatherability tests.
The launch of a space shuttle is a complex and lengthy procedure. There are many places and components to look at and prepare. The components are the orbiter, solid rocket boosters, external tank, and ground equipment. Some of the places are the launch pad, fuel locations, and surrounding structures. Preparations for a launch include equipment checks, system checks, sniff checks for hazardous commodities, and countless walkdowns. Throughout these preparations, pad safety personnel must always be on call. This requires three shifts of multiple people to be ready when needed. Also, the pad safety personnel must be available for the non-launch tasks that are always present for both launch pads
As the Goddard Space Flight Center's (GSFC) Flight Dynamics Facility (FDF) continues to ensure mission success in support of Human Space Flight (HSF) and Launch Vehicle (LV) missions, it continues to improve on different areas of mission support. The FDF processes numerous different types of trajectory profiles, and, for each trajectory, the FDF provides multiple acquisition data vectors to the Space Network (SN) White Sands Complex (WSC) for further processing and uplinking to the SN's Tracking and Data Relay Satellites (TDRSs), tracking the vehicle and maintaining communications throughout required support. Some trajectories target a specific orbit plane through Right Ascension of the Ascending Node (RAAN), or yaw, steering, which can yield to high variability across the launch window. Because of this, there can be a large number of trajectory profiles to process and generate acquisition data for that ensure TDRS is accurately pointing to the launch vehicle. Processing many trajectory profiles by FDF and WSC increases the complexity and level of effort associated with support. FDF employs a legacy boundary on the range difference between trajectories, which determines the number of discrete trajectory cases required to maintain communication with TDRS over the full launch window. An analysis was performed to determine a new boundary, taking into consideration current support requirements. The results show the boundary can be expanded beyond the currently employed legacy value without an impact on communication. In doing so, the number of trajectory profiles processed can be reduced, reducing the complexity and level of effort required, with no impact to mission safety.
The Deep Space Network is providing ground support to space agencies of foreign governments as well as to NASA and other agencies of the Federal government which are involved in space activities. DSN funding for support of missions other than NASA are on either a cooperative or a reimbursable basis. Cooperative funding and support are accomplished in the same manner as NASA sponsored missions. Reimbursable launch funding and support methods are described.
The future of Space Exploration includes missions to the moon, asteroids, Mars, and beyond. To get there, the mission concept is to launch multiple launch vehicles months, even years apart. In order to achieve this, launch vehicles, payloads (satellites and crew capsules), and ground systems must be highly reliable and/or available, to include maintenance concepts and procedures in the event of a launch scrub. In order to achieve this high probability of mission success, Ground Systems Development and Operations (GSDO) has allocated Reliability, Maintainability, and Availability (RMA) requirements to all hardware and software required for both launch operations and, in the event of a launch scrub, required to support a repair of the ground systems, launch vehicle, or payload. This is done concurrently with the design process (30/60/90 reviews).
The use of wind profiling radars during Space Shuttle launches is examined. The way in which wind measurements are used in the launch process is described, including monitoring the day of launch winds, flight simulations, and the improvement of the data base which provides the mean winds and monthly variability of wind profiles. Results are presented from tests of two profilers conducted during March and April, 1985. The wind profiling characteristics of three profilers are listed and the winds provided by the profilers are compared to Jimsphere winds.
The activity under this grant concentrated on: (1) post-launch calibration of the HARP instrument; and (2) analysis and interpretation of the data from the HARP and other related instruments. The HARP was taken by scientists and engineers from the Hungarian Central Research Institute for Physics (CRIP) to NASA/MSFC for calibration in their plasma chamber, with partial support of this grant. This electron and ion calibration of the HARP, helped in transforming measured currents to actual flux values. The analysis and interpretation of the data, carried out jointly by our Russian and Hungarian colleagues and us, led to a number of journal publications and presentations at scientific meetings.
Presented are orbit and attitude determination results from the launch of Satellite Business Systems (SBS)-5 satellite on September 8, 1988 by Arianespace. SBS-5 is a (HS-376) spin stabilized spacecraft. The launch vehicle injected the spacecraft into a low inclination transfer orbit. Apogee motor firing (AMF) attitude was achieved with trim maneuvers. An apogee kick motor placed the spacecraft into drift orbit. Postburn, reorientation and spindown maneuvers were performed during the next 25 hours. The spacecraft was on-station 19 days later. The orbit and attitude were determined by both an extended Kalman filter and a weighted least squares batch processor. Although the orbit inclination was low and the launch was near equinox, post-AMF analysis indicated an attitude declination error of 0.034 deg., resulting in a saving of 8.5 pounds of fuel. The AMF velocity error was 0.4 percent below nominal. The post-AMF drift rate was determined with the filter only 2.5 hours after motor firing. The filter was used to monitor and retarget the reorientation to orbit normal in real time.
The goal of this project is to create a website that displays video, countdown clock, and event times to customers during launches, without needing to be connected to the internal operations network. The requirements of this project are to also minimize the delay in the clock and events to be less than two seconds. The two parts of this are the webpage, which will display the data and videos to the user, and a server to send clock and event data to the webpage. The webpage is written in HTML with CSS and JavaScript. The JavaScript is responsible for connecting to the server, receiving new clock data, and updating the webpage. JavaScript is used for this because it can send custom HTTP requests from the webpage, and provides the ability to update parts of the webpage without having to refresh the entire page. The server application will act as a relay between the operations network, and the open internet. On the operations network side, the application receives multicast packets that contain countdown clock and events data. It will then parse the data into current countdown times and events, and create a packet with that information that can be sent to webpages. The other part will accept HTTP requests from the webpage, and respond to them with current data. The server is written in C# with some C++ files used to define the structure of data packets. The videos for the webpage will be shown in an embedded player from UStream.
An airborne field mill (ABFM) system was implemented on a Learjet 36A and was used to collect electric-field and microphysical data for summertime convective clouds near Cape Canaveral and the Kennedy Space Center. This system is described and the method used for calibrating it is outlined. Data from this ABFM system were used to investigate the relationship between the strengths of electric fields at the boundaries of summer maritime convective clouds and the distances from these cloud where the fields could first be detected by this system. The relationship between the electric-field strengths at the boundaries of convective clouds and selected radar-measurable parameters of these clouds were also investigated. This study shows promise that the radar volume of these clouds can be used to estimate the order of magnitude electric-field intensity. It is possible that selected remote radar measurements could be incorporated into the launch commit criteria as a means of providing greater confidence and flexibility for determining safe stand-off distances for launch vehicles from convective clouds.
A payload was designed which included a cryogenic oxidizer tank, a fuel tank, and burner section. Release of 30 lb of chemicals was planned to occur in 2 seconds at the optimum oxidizer to fuel ratio. The chemicals consisted of 17 lb of liquid fluorine oxidizer and 13 lb of hydrazine-barium salt fuel mixture. The fuel mixture was 17% barium chloride, 16% barium nitrate, and 67% hydrazine, and contained 2.6 lb of available barium. Two significant problem areas were resolved during the program: explosive valve development and burner operation. The release payload was flight tested, from Wallops Island, Virginia. The release took place at an altitude of approximately 260 km. The release produced a luminous cloud which expanded very rapidly, disappearing to the human eye in about 20 seconds. Barium ion concentration slowly increased over a wide area of sky until measurements were discontinued at sunrise (about 30 minutes).
Analysis methods and testing processes are essential activities in the engineering development and verification of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS). Central to mission success is reliable verification of the Mission and Fault Management (M&FM) algorithms for the SLS launch vehicle (LV) flight software. This is particularly difficult because M&FM algorithms integrate and operate LV subsystems, which consist of diverse forms of hardware and software themselves, with equally diverse integration from the engineering disciplines of LV subsystems. M&FM operation of SLS requires a changing mix of LV automation. During pre-launch the LV is primarily operated by the Kennedy Space Center (KSC) Ground Systems Development and Operations (GSDO) organization with some LV automation of time-critical functions, and much more autonomous LV operations during ascent that have crucial interactions with the Orion crew capsule, its astronauts, and with mission controllers at the Johnson Space Center. M&FM algorithms must perform all nominal mission commanding via the flight computer to control LV states from pre-launch through disposal and also address failure conditions by initiating autonomous or commanded aborts (crew capsule escape from the failing LV), redundancy management of failing subsystems and components, and safing actions to reduce or prevent threats to ground systems and crew. To address the criticality of the verification testing of these algorithms, the NASA M&FM team has utilized the State Flow environment6 (SFE) with its existing Vehicle Management End-to-End Testbed (VMET) platform which also hosts vendor-supplied physics-based LV subsystem models. The human-derived M&FM algorithms are designed and vetted in Integrated Development Teams composed of design and development disciplines such as Systems Engineering, Flight Software (FSW), Safety and Mission Assurance (S&MA) and major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GN&C), Thrust Vector Control (TVC), liquid engines, and the astronaut crew office. Since the algorithms are realized using model-based engineering (MBE) methods from a hybrid of the Unified Modeling Language (UML) and Systems Modeling Language (SysML), SFE methods are a natural fit to provide an in depth analysis of the interactive behavior of these algorithms with the SLS LV subsystem models. For this, the M&FM algorithms and the SLS LV subsystem models are modeled using constructs provided by Matlab which also enables modeling of the accompanying interfaces providing greater flexibility for integrated testing and analysis, which helps forecast expected behavior in forward VMET integrated testing activities. In VMET, the M&FM algorithms are prototyped and implemented using the same C++ programming language and similar state machine architectural concepts used by the FSW group. Due to the interactive complexity of the algorithms, VMET testing thus far has verified all the individual M&FM subsystem algorithms with select subsystem vendor models but is steadily progressing to assessing the interactive behavior of these algorithms with LV subsystems, as represented by subsystem models. The novel SFE applications has proven to be useful for quick look analysis into early integrated system behavior and assessment of the M&FM algorithms with the modeled LV subsystems. This early MBE analysis generates vital insight into the integrated system behaviors, algorithm sensitivities, design issues, and has aided in the debugging of the M&FM algorithms well before full testing can begin in more expensive, higher fidelity but more arduous environments such as VMET, FSW testing, and the Systems Integration Lab7 (SIL). SFE has exhibited both expected and unexpected behaviors in nominal and off nominal test cases prior to full VMET testing. In many findings, these behavioral characteristics were used to correct the M&FM algorithms, enable better test coverage, and develop more effective test cases for each of the LV subsystems. This has improved the fidelity of testing and planning for the next generation of M&FM algorithms as the SLS program evolves from non-crewed to crewed flight, impacting subsystem configurations and the M&FM algorithms that control them. SFE analysis has improved robustness and reliability of the M&FM algorithms by revealing implementation errors and documentation inconsistencies. It is also improving planning efficiency for future VMET testing of the M&FM algorithms hosted in the LV flight computers, further reducing risk for the SLS launch infrastructure, the SLS LV, and most importantly the crew.
The Launch Decision Support System (LDSS) is software to be used by the NASA Test Director (NTD) in the firing room during countdown. This software is designed to assist the NTD with time management, that is, when to resume from a hold condition. This software will assist the NTD in making and evaluating alternate plans and will keep him advised of the existing situation. As such, the interface to this software must be designed to provide the maximum amount of information in the clearest fashion and in a timely manner. This research involves applying user interface guidelines to a mature prototype of LDSS and developing displays that will enable the users to easily and efficiently obtain information from the LDSS displays. This research also extends previous work on organizing and prioritizing human-computer interaction knowledge.
Prior to launch, the space shuttle might be described as a very large thermos bottle containing substantial quantities of cryogenic fuels. Because thermal insulation is a critical design requirement, the external wall of the launch vehicle fuel tank is covered with an insulating foam layer. This foam is fragile and can be damaged by very minor impacts, such as that from small- to medium-size hail, which may go unnoticed. In May 1999, hail damage to the top of the External Tank (ET) of STS-96 required a rollback from the launch pad to the Vehicle Assembly Building (VAB) for repair of the insulating foam. Because of the potential for hail damage to the ET while exposed to the weather, a vigilant hail sentry system using impact transducers was developed as a hail damage warning system and to record and quantify hail events. The Kennedy Space Center (KSC) Hail Monitor System, a joint effort of the NASA and University Affiliated Spaceport Technology Development Contract (USTDC) Physics Labs, was first deployed for operational testing in the fall of 2006. Volunteers from the Community Collaborative Rain. Hail, and Snow Network (CoCoRaHS) in conjunction with Colorado State University were and continue to be active in testing duplicate hail monitor systems at sites in the hail prone high plains of Colorado. The KSC Hail Monitor System (HMS), consisting of three stations positioned approximately 500 ft from the launch pad and forming an approximate equilateral triangle (see Figure 1), was deployed to Pad 39B for support of STS-115. Two months later, the HMS was deployed to Pad 39A for support of STS-116. During support of STS-117 in late February 2007, an unusual hail event occurred in the immediate vicinity of the exposed space shuttle and launch pad. Hail data of this event was collected by the HMS and analyzed. Support of STS-118 revealed another important application of the hail monitor system. Ground Instrumentation personnel check the hail monitors daily when a vehicle is on the launch pad, with special attention after any storm suspected of containing hail. If no hail is recorded by the HMS, the vehicle and pad inspection team has no need to conduct a thorough inspection of the vehicle immediately following a storm. On the afternoon of July 13, 2007, hail on the ground was reported by observers at the VAB, about three miles west of Pad 39A, as well as at several other locations around Kennedy Space Center. The HMS showed no impact detections, indicating that the shuttle had not been damaged by any of the numerous hail events which occurred that day.