Search NASASearch

SEARCH · Search NASA

Results for “launch control systems”

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 127 records · Page 7

Launch Processing System

This paper presents a functional description of the Launch Processing System, which provides automatic ground checkout and control of the Space Shuttle launch site and airborne systems, with emphasis placed on the Checkout, Control, and Monitor Subsystem. Hardware and software modular design concepts for the distributed computer system are reviewed relative to performing system tests, launch operations control, and status monitoring during ground operations. The communication network design, which uses a Common Data Buffer interface to all computers to allow computer-to-computer communication, is discussed in detail.

Byrne, F.

Advanced Modeling of Control-Structure Interaction in Thrust Vector Control Systems

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (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. Two actuators are used to move each engine in two planes perpendicular to one another (i.e., pitch and yaw). The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. During the development of the SLS TVC system, a family of advanced dynamics models were developed to extend and compliment the simplified quasi-linear “simplex” model historically used for flight control design and stability analysis. The importance of these advanced models became increasingly evident after ambient and hot fire testing of the Core Stage, which revealed a number of findings associated with the dynamic response of the TVC integrated system. Test responses suggested that the TVC did not meet its performance specifications and its step and frequency responses exhibited unexpected departures from prior lab tests and modeled behavior. One driving factor for these results was a higher-than-expected degree of coupling between the TVC system, the engine dynamics, and the Core Stage structure. This paper is the third 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, a new method of modeling rocket vehicle thrust vectoring servoelastic dynamics is presented. In this approach, the load dynamics are replaced by a detailed finite element model containing both the rigid body and elastic modes. A partitioning technique is used to compute the effective compliance from the modal data and obtain accurate simulation results using a reduced number of generalized coordinates. Coupled backup structure and nozzle attach compliance effects on multiple engines are captured in higher fidelity than with a spring approximation, eliciting novel effects due to the complex load paths involved in the Core Stage structure. Validation of the model is demonstrated using a variety of structural/modal, laboratory, and full-scale hot fire test data.

Launch Vehicles

Advanced Modeling of Control-Structure Interaction in Thrust Vector Control Systems

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (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. Two actuators are used to move each engine in two planes perpendicular to one another (i.e., pitch and yaw). The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. During the development of the SLS TVC system, a family of advanced dynamics models were developed to extend and compliment the simplified quasi-linear “simplex” model historically used for flight control design and stability analysis. The importance of these advanced models became increasingly evident after ambient and hot fire testing of the Core Stage, which revealed a number of findings associated with the dynamic response of the TVC integrated system. Test responses suggested that the TVC did not meet its performance specifications and its step and frequency responses exhibited unexpected departures from prior lab tests and modeled behavior. One driving factor for these results was a higher-than-expected degree of coupling between the TVC system, the engine dynamics, and the Core Stage structure. This paper is the third 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, a new method of modeling rocket vehicle thrust vectoring servoelastic dynamics is presented. In this approach, the load dynamics are replaced by a detailed finite element model containing both the rigid body and elastic modes. A partitioning technique is used to compute the effective compliance from the modal data and obtain accurate simulation results using a reduced number of generalized coordinates. Coupled backup structure and nozzle attach compliance effects on multiple engines are captured in higher fidelity than with a spring approximation, eliciting novel effects due to the complex load paths involved in the Core Stage structure. Validation of the model is demonstrated using a variety of structural/modal, laboratory, and full-scale hot fire test data.

Launch Vehicles

A feedback control for the advanced launch system

A robust feedback algorithm is presented for a near-minimum-fuel ascent of a two-stage launch vehicle operating in the equatorial plane. The development of the algorithm is based on the ideas of neighboring optimal control and can be derived into three phases. In phase 1, the formalism of optimal control is employed to calculate fuel-optimal ascent trajectories for a simple point-mass model. In phase 2, these trajectories are used to numerically calculate gain functions of time for the control(s), the total flight time, and possibly, for other variables of interest. In phase 3, these gains are used to determine feedback expressions for the controls associated with a more realistic model of a launch vehicle. With the Advanced Launch System in mind, all calculations are performed on a two-stage vehicle with fixed thrust history, but this restriction is by no means important for the approach taken. Performance and robustness of the algorithm is found to be excellent.

Seywald, Hans

Demonstration of the Dynamic Flowgraph Methodology using the Titan 2 Space Launch Vehicle Digital Flight Control System

Dynamic Flowgraph Methodology (DFM) is a new approach developed to integrate the modeling and analysis of the hardware and software components of an embedded system. The objective is to complement the traditional approaches which generally follow the philosophy of separating out the hardware and software portions of the assurance analysis. In this paper, the DFM approach is demonstrated using the Titan 2 Space Launch Vehicle Digital Flight Control System. The hardware and software portions of this embedded system are modeled in an integrated framework. In addition, the time dependent behavior and the switching logic can be captured by this DFM model. In the modeling process, it is found that constructing decision tables for software subroutines is very time consuming. A possible solution is suggested. This approach makes use of a well-known numerical method, the Newton-Raphson method, to solve the equations implemented in the subroutines in reverse. Convergence can be achieved in a few steps.

Yau, M.

Gimbal Bearing Friction in the SLS Core Stage Thrust Vector Control System

The Space Launch System (SLS) Core Stage Thrust Vector Control (TVC) system is comprised of eight mechanical feedback Shuttle heritage Type III TVC actuators that vector the four Shuttle heritage RS-25 engines about a Shuttle heritage gimbal block/bearing. The MSFC Controls community has long regarded gimbal friction to be a negligible effect on the overall control of gimbaled RS-25 engines. This is corroborated by Space Shuttle test and flight data that does not appear to show degraded effects, nor limit cycling at the end of the shuttle flight. For this reason, friction was not expected to be a driving factor of performance and control of the reused RS-25 engines aboard the SLS. However, after test data showed a large shift in frequency behavior and a highly damped step-response in the time series, there was further investigation into what could have caused this behavior. Heritage friction models used in previous gimbal and ball bearings were evaluated such as Coulomb, Dahl and LuGre, but the single degree of freedom friction models alone were not enough to explain the behavior and shifts seen in the test data. This paper presents the additional findings and modeling efforts regarding friction on the RS-25 engines. Using the Two Actuator Operational Simulation (TAOS), the difference from modeling separate friction degrees of freedom to coupled degrees of freedom was investigated to deduce the effects of one axis’s movement on the other. Next, due to the vibration environment, a modified LuGre model has been proposed that adds an additional term to decrease the friction coefficient at low engine velocity amplitudes. Lastly, the addition of the stiffness in each half of the gimbal bearing has increased modeling fidelity by also adding the effect on the gimbal bearing bending in compliance to both the friction torque on the surface of the gimbal bearing and the actuator force that is forcing the engine in a specified direction. Through these effects, the time and frequency domain behavior seen in test can be characterized accurately.

Friction

Gimbal Bearing Friction in the SLS Core Stage Thrust Vector Control System

The Space Launch System (SLS) Core Stage Thrust Vector Control (TVC) system is comprised of eight mechanical feedback Shuttle heritage Type III TVC actuators that vector the four Shuttle heritage RS-25 engines about a Shuttle heritage gimbal block/bearing. The MSFC Controls community has long regarded gimbal friction to be a negligible effect on the overall control of gimbaled RS-25 engines. This is corroborated by Space Shuttle test and flight data that does not appear to show degraded effects, nor limit cycling at the end of the shuttle flight. For this reason, friction was not expected to be a driving factor of performance and control of the reused RS-25 engines aboard the SLS. However, after test data showed a large shift in frequency behavior and a highly damped step-response in the time series, there was further investigation into what could have caused this behavior. Heritage friction models used in previous gimbal and ball bearings were evaluated such as Coulomb, Dahl and LuGre, but the single degree of freedom friction models alone were not enough to explain the behavior and shifts seen in the test data. This paper presents the additional findings and modeling efforts regarding friction on the RS-25 engines. Using the Two Actuator Operational Simulation (TAOS), the difference from modeling separate friction degrees of freedom to coupled degrees of freedom was investigated to deduce the effects of one axis’s movement on the other. Next, due to the vibration environment, a modified LuGre model has been proposed that adds an additional term to decrease the friction coefficient at low engine velocity amplitudes. Lastly, the addition of the stiffness in each half of the gimbal bearing has increased modeling fidelity by also adding the effect on the gimbal bearing bending in compliance to both the friction torque on the surface of the gimbal bearing and the actuator force that is forcing the engine in a specified direction. Through these effects, the time and frequency domain behavior seen in test can be characterized accurately.

Friction

Space Launch System: Core Stage Thrust Vector Control Systems Engineering Challenges in Reusing Heritage Hardware

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (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. Two actuators are used to move each engine in two planes perpendicular to one another (i.e., pitch and yaw). 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 Core Auxiliary Power Unit (CAPU) is derived from the Orbiter Auxiliary Power Unit (APU). The Orbiter and Solid Rocket Booster APU turbines are powered by hot gas produced by catalyzed hydrazine decomposition. 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. While direct reuse or slight modification of existing hardware may seem to be a triple-win for a program in cost, schedule, and technical risk mitigation, those benefits can only be realized when its degree of application in a new system is carefully and thoughtfully managed. The heritage hardware reuse should be prescribed within the heritage design capability and reuse environments must lie within the envelope of heritage qualification testing. Despite the significant test and flight experience of the Shuttle heritage hardware components, successful integration with the newly designed CS TVC components and incorporation into the stage design proved to be a challenge which required re-qualification of the heritage hardware as well as thorough integrated testing to support flight certification. Examples of the challenges that were overcome include: re-qualifying heritage hardware to survive new shock and vibration environments, certifying performance of extensively modified heritage hardware, regenerating design insight due to lack of available heritage vendor data, showing compliance to modern structural design standards, translation of heritage requirements for analog avionics to modern digital avionics, and interfacing heritage mechanical hardware with newly designed avionics. This paper is the second installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. This paper will discuss several engineering challenges encountered during the development process for SLS CS TVC and how they were successfully overcome to reach flight readiness.

Thrust Vector Control

Launch delay impact on the Galileo attitude control system

The Galileo spacecraft was launched from the Space Shuttle in October 1989, using a two-stage inertial upper stage. The trajectory included flybys of Venus and earth for gravity assists. The mission duration increased to a total of 8 years rather than the original 4.5 years. The major impact of this new mission plan was on the thermal control design. A viable design was achieved, with one major attitude control constraint: the spacecraft antenna boresight must be pointed to within 14 deg of the sun whenever the spacecrat is within 1 AU of the sun, even in the presence of faults. Changes to hardware, software and operations strategies had to be made to handle the new and longer mission.

Chodas, J. L.

Voyager spacecraft attitude control propulsion system post-launch performance requirements changes

A test program aimed at the re-qualification of the 0.2-lbf attitude control thruster of the Voyager 2 spacecraft was carried out while the spacecraft was in flight on an interplanetary trajectory to Uranus. The objective of the program was to determine if the 0.2-lbf thruster could be successfully and repeatedly fired at pulse widths of less than the standard minimum pulse width of 10 milliseconds with no degradation. It was demonstrated that the thruster was qualified for short pulse operation at pulse widths of 4 ms or greater. Pulse widths of 4.0 ms provide an impulse bit of approximately 45 percent of the impulse provided by a 10-ms pulse, and the pulse-to-pulse and unit-to-unit variation is approximately plus or minus 10 percent.

Groudle, T. A.

Command and Control System Automated Testing

The Kennedy Space Center (KSC) has developed its own Command and Control System for the launch of the Space Launch System (SLS) and Orion capsule. The Command and Control System (CCS) is used by console engineers for the launch and system checkout of aerospace vehicles. The CCS allows console engineers to read data from the flight hardware on the launch pad and from the ground control systems and allows console engineers to issue commands, like opening a valve, to the flight hardware and ground control systems. The CCS needs to interact with thousands of devices and hardware controllers for the spacecraft and ground systems, receive data from these devices, distribute the data to console engineers in real-time, and allow console engineers to issue commands to manipulate hardware on the launch pad. The system needs to be robust, fault tolerant, responsive, and fast. In order to keep up with the pace of development of the CCS, a Test Automation System (TAS) is needed to validate the integrity of the system as a whole along with its individual components. Automated tests allow for faster development time, since tests can be ran through a Continuous Integration system and allow developers to check their code faster. Currently, the different modules, classes, and functions that make up the CCS are tested at the unit level, and the system level, with all the modules working together. My project was to implement a system for the data protocol layer of the Command Control System to be tested as a complete functional unit, with all of its classes and functions working together, but independent of the other modules of the CCS.

Automated TestingTest Automation

The development of a pseudo-nyquist analysis technique for hybrid sampled-data control systems

The stability characteristics of a launch vehicle, as a function of gain and phase variations at the thrust vector controller, cannot be obtained using classical sampled-data control theory if the launch vehicle attitude control system contains both sampled-data and continuous feedback control loops. A method was developed which can be used to generate a sampled-data pseudo-Nyquist plot for gain and phase variations at the controller. This method was developed and used to determine the stability characteristics of the Saturn 1B launch vehicle in the backup guidance mode.

Burnitt, M. G.

NASA Ares I Launch Vehicle Upper Stage Reaction Control System (ReCS) Cold Flow Development Test Overview

NASA s Ares I launch vehicle, consisting of a five segment solid rocket booster first stage and a liquid bi-propellant J2-X engine Upper Stage, is the vehicle that s been chosen to launch the Orion Crew Module, which will return humans to the Moon, Mars, and beyond. After First Stage booster separation, the Reaction Control System (ReCS), a monopropellant hydrazine system, will provide the Upper Stage element with three degrees of freedom control as needed. This paper provides an overview of the system level development testing that has taken place on the Ares I launch vehicle Upper Stage ReCS. The ReCS System Development Test Article (SDTA) was built as a flight representative water flow test article whose primary test objective was to obtain fluid system performance data to evaluate the integrate system performance characteristics and verify analytical models. Water is the industry standard for cold flow testing of hydrazine systems, because the densities are very close and the speeds of sound are well characterized. The completion of this development level test program was considered necessary to support the ReCS Critical Design Review. This paper will address the design approach taken in building the test article, the objectives of the test program, types of testing completed, general results, the ability of the program to meet the test objectives, and lessons learned

Dervan, Melanie

Saturn v system philosophies.

Saturn V launch control and checkout system discussing interconnected computer complexes, digital and video displays and programming methods

COMPUTER PROGRAM

Orion Crew Exploration Vehicle Launch Abort System Guidance and Control Analysis Overview

Aborts during the critical ascent flight phase require the design and operation of Orion Crew Exploration Vehicle (CEV) systems to escape from the Crew Launch Vehicle (CLV) and return the crew safely to the Earth. To accomplish this requirement of continuous abort coverage, CEV ascent abort modes are being designed and analyzed to accommodate the velocity, altitude, atmospheric, and vehicle configuration changes that occur during ascent. Aborts from the launch pad to early in the flight of the CLV second stage are performed using the Launch Abort System (LAS). During this type of abort, the LAS Abort Motor is used to pull the Crew Module (CM) safely away from the CLV and Service Module (SM). LAS abort guidance and control studies and design trades are being conducted so that more informed decisions can be made regarding the vehicle abort requirements, design, and operation. This paper presents an overview of the Orion CEV, an overview of the LAS ascent abort mode, and a summary of key LAS abort analysis methods and results.

Davidson, John B.

Command and Control System Software Development

With the first launch of the National Aeronautics and Space Administration's Space Launch System heavy-lift expendable launch vehicle and Lockheed Martin's Orion Multi-Purpose Crew Vehicle scheduled for the year 2020, there exists a need to complete development of a new command and control system that will provide systems monitoring and launch control for NASA's Exploration Missions. One remaining task necessary for completion of this command and control system is to create and maintain comprehensive unit tests of the control system software packages. These tests should verify that the implementation of all required and desired functionality works as intended. This testing infrastructure is mostly in place, but the control system's open source automation server still reports software "bugs" (possible flaws or failures which may lead to unintended behavior) and intermittently failing unit tests. Since code correctness is of critical importance for human rated software systems, I was assigned to diagnose the root cause of failing unit tests, eliminate non-determinism in these tests, and fix bugs as reported by the automation server.

GUI