Search NASA⌕ Search

SEARCH · Search NASA

Results for “launch software”

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 307 records · Page 17

Space Shuttle Dynamic Integrated Tests - Concept and results for STS-1

It is pointed out that ground tests, which involve end-to-end checks of various subsystems often by stimulating an input device and examining the resultant effect, do not exercise dynamically all subsystem interactions encountered during a real flight. The development and implementation of the Dynamic Integrated Test (DIT) for the Space Transportation System, patterned on the ASIST (Avionics System Integration Self Test) concept, are examined. It is noted that the complete hardware-software data paths which are utilized in flight simply do not exist until the vehicle is assembled. The integrated test is considered necessary in order to verify the integrity of these paths, that is, to establish that proper connections have been made, that correct polarity is maintained, and that no unexpected interference is generated. As a result of four tests carried out on the Space Transportation System, hardware and software problems, both on-board the vehicle and within the launch support complex, were identified and resolved. Significant return was also realized in the training of the launch and flight crews.

Brody, S.↗

A case study of a system engineered for control by humans

Alternatives to the traditional concepts for real time health and safety operations were examined. The pitfalls of the conventional contingency planning for health and safety are highlighted. The Solar Maximum Mission (SMM) contingency planning and operations provides the evolution from the conventional people intensive health and safety operation, toward a night watchman mode of operations. The SMM spacecraft health and safety operations were budget constrained to the point that one operator was responsible for the health and safety of the entire spacecraft one week after launch. The spacecraft was a protoflight with brand new subsystem configurations, software and procedures. To manage the risks associated with this one man SMM health and safety operation, the real time contingency planning and operations centered around unambiguously identifying a system level problem, and reactively safing components susceptible to unrecoverable damage. The methodology applied to both analyzing and implementing this approach of SMM is shown.

Rothenberg, J.↗

Vibroacoustic payload environment prediction system (VAPEPS): Data base management center remote access guide

A Vibroacoustic Data Base Management Center has been established at the Jet Propulsion Laboratory (JPL). The center utilizes the Vibroacoustic Payload Environment Prediction System (VAPEPS) software package to manage a data base of shuttle and expendable launch vehicle flight and ground test data. Remote terminal access over telephone lines to a dedicated VAPEPS computer system has been established to provide the payload community a convenient means of querying the global VAPEPS data base. This guide describes the functions of the JPL Data Base Management Center and contains instructions for utilizing the resources of the center.

Thomas, V. C.↗

Advanced information processing system for advanced launch system: Avionics architecture synthesis

The Advanced Information Processing System (AIPS) is a fault-tolerant distributed computer system architecture that was developed to meet the real time computational needs of advanced aerospace vehicles. One such vehicle is the Advanced Launch System (ALS) being developed jointly by NASA and the Department of Defense to launch heavy payloads into low earth orbit at one tenth the cost (per pound of payload) of the current launch vehicles. An avionics architecture that utilizes the AIPS hardware and software building blocks was synthesized for ALS. The AIPS for ALS architecture synthesis process starting with the ALS mission requirements and ending with an analysis of the candidate ALS avionics architecture is described.

Lala, Jaynarayan H.↗

Rapid design of gravity assist trajectories

Several International Solar-Terrestrial Physics (ISTP) missions require the design of complex gravity-assisted trajectories in order to investigate the interaction of the solar wind with the earth's magnetic field. These trajectories present a formidable trajectory design and optimization problem. This paper discusses the philosophy and methodology that enable an analyst to design and analyze such trajectories. The authors describe what is called 'floating end-point' targeting, which allows the inherently nonlinear multiple body problem to be solved with simple linear techniques. This paper demonstrates how floating end-point targeting combines analytic approximations with a Newton method targeter to achieve trajectory design goals quickly, even for the very sensitive double lunar swingby trajectories used by the ISTP missions. A Multiconic orbit integration scheme allows fast and accurate orbit propagation. This paper also describes a prototype software tool, Swingby, which has been built for trajectory design and launch window analysis.

Carrico, J.↗

Advanced information processing system: Hosting of advanced guidance, navigation and control algorithms on AIPS using ASTER

This program demonstrated the integration of a number of technologies that can increase the availability and reliability of launch vehicles while lowering costs. Availability is increased with an advanced guidance algorithm that adapts trajectories in real-time. Reliability is increased with fault-tolerant computers and communication protocols. Costs are reduced by automatically generating code and documentation. This program was realized through the cooperative efforts of academia, industry, and government. The NASA-LaRC coordinated the effort, while Draper performed the integration. Georgia Institute of Technology supplied a weak Hamiltonian finite element method for optimal control problems. Martin Marietta used MATLAB to apply this method to a launch vehicle (FENOC). Draper supplied the fault-tolerant computing and software automation technology. The fault-tolerant technology includes sequential and parallel fault-tolerant processors (FTP & FTPP) and authentication protocols (AP) for communication. Fault-tolerant technology was incrementally incorporated. Development culminated with a heterogeneous network of workstations and fault-tolerant computers using AP. Draper's software automation system, ASTER, was used to specify a static guidance system based on FENOC, navigation, flight control (GN&C), models, and the interface to a user interface for mission control. ASTER generated Ada code for GN&C and C code for models. An algebraic transform engine (ATE) was developed to automatically translate MATLAB scripts into ASTER.

Brenner, Richard↗

Monte Carlo Simulation to Estimate Likelihood of Direct Lightning Strikes

A software tool has been designed to quantify the lightning exposure at launch sites of the stack at the pads under different configurations. In order to predict lightning strikes to generic structures, this model uses leaders whose origins (in the x-y plane) are obtained from a 2D random, normal distribution.

Mata, Carlos↗

Integrated Main Propulsion System Performance Reconstruction Process/Models

The Integrated Main Propulsion System (MPS) Performance Reconstruction process provides the MPS post-flight data files needed for postflight reporting to the project integration management and key customers to verify flight performance. This process/model was used as the baseline for the currently ongoing Space Launch System (SLS) work. The process utilizes several methodologies, including multiple software programs, to model integrated propulsion system performance through space shuttle ascent. It is used to evaluate integrated propulsion systems, including propellant tanks, feed systems, rocket engine, and pressurization systems performance throughout ascent based on flight pressure and temperature data. The latest revision incorporates new methods based on main engine power balance model updates to model higher mixture ratio operation at lower engine power levels.

Lopez, Eduardo↗

How X-37 Technology Demonstration Supports Reusable Launch Vehicles

This presentation discusses, in viewgraph form, how X-37 Technology Demonstration Supports Reusable Launch Vehicles. The topics include: 1) X-37 Program Objectives; 2) X-37 Description; 3) X-37 Vehicle Characteristics; 4) X-37 Expands the Testbed Envelope to Orbital Capability; 5) Overview of X-37 Flight Test Program; 6) Thirty-Nine Technologies and Experiments are Being Demonstrated on the X-37; 7) X-37 Airframe/Structures Technologies; 8) X-37 Mechanical, Propulsion, and Thermal System Technologies and Experiments; 9) X-37 GN&C Technologies; 10) X-37 Avionics, Power, and Software Technologies and Experiments; and 11) X-37 Technologies and Experiments Support Reusable Launch Vehicle Needs.

Manley, David J.↗

NASA's Software Safety Standard

NASA relies more and more on software to control, monitor, and verify its safety critical systems, facilities and operations. Since the 1960's there has hardly been a spacecraft launched that does not have a computer on board that will provide command and control services. There have been recent incidents where software has played a role in high-profile mission failures and hazardous incidents. For example, the Mars Orbiter, Mars Polar Lander, the DART (Demonstration of Autonomous Rendezvous Technology), and MER (Mars Exploration Rover) Spirit anomalies were all caused or contributed to by software. The Mission Control Centers for the Shuttle, ISS, and unmanned programs are highly dependant on software for data displays, analysis, and mission planning. Despite this growing dependence on software control and monitoring, there has been little to no consistent application of software safety practices and methodology to NASA's projects with safety critical software. Meanwhile, academia and private industry have been stepping forward with procedures and standards for safety critical systems and software, for example Dr. Nancy Leveson's book Safeware: System Safety and Computers. The NASA Software Safety Standard, originally published in 1997, was widely ignored due to its complexity and poor organization. It also focused on concepts rather than definite procedural requirements organized around a software project lifecycle. Led by NASA Headquarters Office of Safety and Mission Assurance, the NASA Software Safety Standard has recently undergone a significant update. This new standard provides the procedures and guidelines for evaluating a project for safety criticality and then lays out the minimum project lifecycle requirements to assure the software is created, operated, and maintained in the safest possible manner. This update of the standard clearly delineates the minimum set of software safety requirements for a project without detailing the implementation for those requirements. This allows the projects leeway to meet these requirements in many forms that best suit a particular project's needs and safety risk. In other words, it tells the project what to do, not how to do it. This update also incorporated advances in the state of the practice of software safety from academia and private industry. It addresses some of the more common issues now facing software developers in the NASA environment such as the use of Commercial-Off-the-Shelf Software (COTS), Modified OTS (MOTS), Government OTS (GOTS), and reused software. A team from across NASA developed the update and it has had both NASA-wide internal reviews by software engineering, quality, safety, and project management. It has also had expert external review. This presentation and paper will discuss the new NASA Software Safety Standard, its organization, and key features. It will start with a brief discussion of some NASA mission failures and incidents that had software as one of their root causes. It will then give a brief overview of the NASA Software Safety Process. This will include an overview of the key personnel responsibilities and functions that must be performed for safety-critical software.

Ramsay, Christopher M.↗

Coupled Fluid-Structure Interaction Analysis of Solid Rocket Motor with Flexible Inhibitors

Flexible inhibitors are generally used in solid rocket motors (SRMs) as a means to control the burning of propellant. Vortices generated by the flow of propellant around the flexible inhibitors have been identified as a driving source of instabilities that can lead to thrust oscillations in launch vehicles. Potential coupling between the SRM thrust oscillations and structural vibration modes is an important risk factor in launch vehicle design. As a means to predict and better understand these phenomena, a multidisciplinary simulation capability that couples the NASA production CFD code, Loci/CHEM, with CFDRC's structural finite element code, CoBi, has been developed. This capability is crucial to the development of NASA's new space launch system (SLS). This paper summarizes the efforts in applying the coupled software to demonstrate and investigate fluid-structure interaction (FSI) phenomena between pressure waves and flexible inhibitors inside reusable solid rocket motors (RSRMs). The features of the fluid and structural solvers are described in detail, and the coupling methodology and interfacial continuity requirements are then presented in a general Eulerian-Lagrangian framework. The simulations presented herein utilize production level CFD with hybrid RANS/LES turbulence modeling and grid resolution in excess of 80 million cells. The fluid domain in the SRM is discretized using a general mixed polyhedral unstructured mesh, while full 3D shell elements are utilized in the structural domain for the flexible inhibitors. Verifications against analytical solutions for a structural model under a steady uniform pressure condition and under dynamic modal analysis show excellent agreement in terms of displacement distribution and eigenmode frequencies. The preliminary coupled results indicate that due to acoustic coupling, the dynamics of one of the more flexible inhibitors shift from its first modal frequency to the first acoustic frequency of the solid rocket motor. This insight could have profound implications for SRM and flexible inhibitor designs for current and future launch vehicles including SLS.

Yang, H. Q.↗

Simulation Tools Prevent Signal Interference on Spacecraft

NASA engineers use simulation software to detect and prevent interference between different radio frequency (RF) systems on a rocket and satellite before launch. To speed up the process, Kennedy Space Center awarded SBIR funding to Champaign, Illinois-based Delcross Technologies LLC, which added a drag-and-drop feature to its commercial simulation software, resulting in less time spent preparing for the analysis.

Source record↗

GOES-I/M ascent maneuvers from transfer orbit to station

The Geostationary Operational Environmental Satellite (GOES)-I/M station acquisition sequence consists nominally of three in-plane/out-of-plane maneuvers at apogee on the line of relative nodes and a small in-plane maneuver at perigee. Existing software to determine maneuver attitude, ignition time, and burn duration required modification to optimize the out-of-plane parts and admit the noninertial, three-axis stabilized attitude. The Modified Multiple Impulse Station Acquisition Maneuver Planning Program (SENARIO2) was developed from its predecessor, SCENARIO, to optimize the out-of-plane components of the impulsive delta-V vectors. Additional new features include commputation of short term J sub 2 perturbations and output of all premaneuver and postmaneuver orbit elements, coarse maneuver attitudes, propellant usage, spacecraft antenna aspect angles, and ground station coverage. The output data are intended to be used in the launch window computation and by the maneuver targeting computation (General Maneuver (GMAN) Program) software. The maneuver targeting computation in GMAN was modified to admit the GOES-I/M maneuver attitude. Appropriate combinations of ignition time, burn duration, and attitude enable any reasonable target orbit to be achieved.

Abeyagunawardene, S.↗

Overview of the SLS Core Stage Thrust Vector Control System Design

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) consists of four independent hydraulic systems. The SLS CS TVC system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Each hydraulic system nominally provides hydraulic power to one RS-25 engine and two actuators. Additionally, each system provides redundant control capability to one actuator on each of its neighboring systems. The RS-25 uses hydraulic power to control propellant valves, and the TVC actuators are used to move the engine in the pitch and yaw gimbal planes. The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Solid Rocket Booster APU turbines are powered by hot gas produced by a catalyzed hydrazine decomposition. The SLS Core Auxiliary Power Unit (CAPU) is derived from the Space Shuttle Orbiter Auxiliary Power Unit (APU); on the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. The remaining hardware in the TVC system (hydraulic Filter Manifold (FM), hydraulic Supply Accumulator (SA), hydraulic Return Accumulator (RA), Hydraulic Reservoir, Exhaust Gas Heat Exchanger (EGHE)) as well as the avionics providing control and telemetry (TVC Actuator Controller (TAC) and CAPU Controller (CAPUC) are new components developed for SLS. This paper is the first installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the overall design architecture of the CS TVC is presented, with a focus on the interfaces between the TVC actuators, the engines, their hydraulic power systems, and the avionics that provide commands from the SLS Vehicle Management (VM) software to effect stable and robust flight control for the integrated SLS launch vehicle.

Thrust Vector Control↗

Overview of the SLS Core Stage Thrust Vector Control System Design

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) consists of four independent hydraulic systems. The SLS CS TVC system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Each hydraulic system nominally provides hydraulic power to one RS-25 engine and two actuators. Additionally, each system provides redundant control capability to one actuator on each of its neighboring systems. The RS-25 uses hydraulic power to control propellant valves, and the TVC actuators are used to move the engine in the pitch and yaw gimbal planes. The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Solid Rocket Booster APU turbines are powered by hot gas produced by a catalyzed hydrazine decomposition. The SLS Core Auxiliary Power Unit (CAPU) is derived from the Space Shuttle Orbiter Auxiliary Power Unit (APU); on the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. The remaining hardware in the TVC system (hydraulic Filter Manifold (FM), hydraulic Supply Accumulator (SA), hydraulic Return Accumulator (RA), Hydraulic Reservoir, Exhaust Gas Heat Exchanger (EGHE)) as well as the avionics providing control and telemetry (TVC Actuator Controller (TAC) and CAPU Controller (CAPUC) are new components developed for SLS. This paper is the first installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the overall design architecture of the CS TVC is presented, with a focus on the interfaces between the TVC actuators, the engines, their hydraulic power systems, and the avionics that provide commands from the SLS Vehicle Management (VM) software to effect stable and robust flight control for the integrated SLS launch vehicle.

Thrust Vector Control↗

NASA's Software Safety Standard

NASA (National Aeronautics and Space Administration) relies more and more on software to control, monitor, and verify its safety critical systems, facilities and operations. Since the 1960's there has hardly been a spacecraft (manned or unmanned) launched that did not have a computer on board that provided vital command and control services. Despite this growing dependence on software control and monitoring, there has been no consistent application of software safety practices and methodology to NASA's projects with safety critical software. Led by the NASA Headquarters Office of Safety and Mission Assurance, the NASA Software Safety Standard (STD-18l9.13B) has recently undergone a significant update in an attempt to provide that consistency. This paper will discuss the key features of the new NASA Software Safety Standard. It will start with a brief history of the use and development of software in safety critical applications at NASA. It will then give a brief overview of the NASA Software Working Group and the approach it took to revise the software engineering process across the Agency.

Ramsay, Christopher M.↗

Test Telemetry And Command System (TTACS)

The Jet Propulsion Laboratory has developed a multimission Test Telemetry and Command System (TTACS) which provides a multimission telemetry and command data system in a spacecraft test environment. TTACS reuses, in the spacecraft test environment, components of the same data system used for flight operations; no new software is developed for the spacecraft test environment. Additionally, the TTACS is transportable to any spacecraft test site, including the launch site. The TTACS is currently operational in the Galileo spacecraft testbed; it is also being provided to support the Cassini and Mars Surveyor Program projects. Minimal personnel data system training is required in the transition from pre-launch spacecraft test to post-launch flight operations since test personnel are already familiar with the data system's operation. Additionally, data system components, e.g. data display, can be reused to support spacecraft software development; and the same data system components will again be reused during the spacecraft integration and system test phases. TTACS usage also results in early availability of spacecraft data to data system development and, as a result, early data system development feedback to spacecraft system developers. The TTACS consists of a multimission spacecraft support equipment interface and components of the multimission telemetry and command software adapted for a specific project. The TTACS interfaces to the spacecraft, e.g., Command Data System (CDS), support equipment. The TTACS telemetry interface to the CDS support equipment performs serial (RS-422)-to-ethernet conversion at rates between 1 bps and 1 mbps, telemetry data blocking and header generation, guaranteed data transmission to the telemetry data system, and graphical downlink routing summary and control. The TTACS command interface to the CDS support equipment is nominally a command file transferred in non-real-time via ethernet. The CDS support equipment is responsible for metering the commands to the CDS; additionally for Galileo, TTACS includes a real-time-interface to the CDS support equipment. The TTACS provides the basic functionality of the multimission telemetry and command data system used during flight operations. TTACS telemetry capabilities include frame synchronization, Reed-Solomon decoding, packet extraction and channelization, and data storage/query. Multimission data display capabilities are also available. TTACS command capabilities include command generation verification, and storage.

Fogel, Alvin J.↗

Distributed Web-Based Expert System for Launch Operations

The simulation and modeling of launch operations is based on a representation of the organization of the operations suitable to experiment of the physical, procedural, software, hardware and psychological aspects of space flight operations. The virtual test bed consists of a weather expert system to advice on the effect of weather to the launch operations. It also simulates toxic gas dispersion model, and the risk impact on human health. Since all modeling and simulation is based on the internet, it could reduce the cost of operations of launch and range safety by conducting extensive research before a particular launch. Each model has an independent decision making module to derive the best decision for launch.

Bardina, Jorge E.↗