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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 307 records · Page 17

All sources NASA NTRS DOE OSTI

NASA NTRS1994

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↗

NASA NTRS2008

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↗

NASA NTRS2013

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↗

NASA NTRS2000

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 NTRS2007

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.↗

NASA NTRS2014

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.↗

NASA NTRS2014

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↗

NASA NTRS1989

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.↗

NASA NTRSDate not supplied

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 NTRSDate not supplied

Overview of the SLS Core Stage Thrust Vector Control System Design

Thrust Vector Control↗

NASA NTRS2005

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.↗

NASA NTRS1994

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.↗

NASA NTRS2005

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.↗

NASA NTRS2013

Orion GNC Mitigation Efforts for Van Allen Radiation

The Orion Crew Module (CM) is NASA's next generation manned space vehicle, scheduled to return humans to lunar orbit in the coming decade. The Orion avionics and GN&C architectures have progressed through a number of project phases and are nearing completion of a major milestone. The first unmanned test mission, dubbed "Exploration Flight Test One" (EFT-1) is scheduled to launch from NASA Kennedy Space Center late next year and provides the first integrated test of all the vehicle systems, avionics and software. The EFT-1 mission will be an unmanned test flight that includes a high speed re-entry from an elliptical orbit, which will be launched on an expendable launch vehicle (ELV). The ELV will place CM and the ELV upper stage into a low Earth orbit (LEO) for one revolution. After the first LEO, the ELV upper stage will re-ignite and place the combined upper stage/CM into an elliptical orbit whose perigee results in a high energy entry to test CM response in a relatively high velocity, high heating environment. While not producing entry velocities as high as those experienced in returning from a lunar orbit, the trajectory was chosen to provide higher stresses on the thermal protection and guided entry systems, as compared against a lower energy LEO entry. However the required entry geometry with constraints on inclination and landing site result in a trajectory that lingers for many hours in the Van Allen radiation belts. This exposes the vehicle and avionics to much higher levels of high energy proton radiation than a typical LEO or lunar trajectory would encounter. As a result, Van Allen radiation poses a significant risk to the Orion avionics system, and particularly the Flight Control Module (FCM) computers that house the GN&C flight software. The measures taken by the Orion GN&C, Flight Software and Avionics teams to mitigate the risks associated with the Van Allen radiation on EFT-1 are covered in the paper. Background on the Orion avionics subsystem is provided, as well as an overview of the GN&C software architecture. The measures taken to handle radiation induced failure of the one or both of the FCM's are presented, and finally simulation and actual hardware-in-the-loop (HWIL) results are shown confirming the validity of the implementation. The paper presents an overview of the Orion avionics architecture describing the GNC sensors, onboard data network as well as the flight control computers and their planned restart capabilities. GN&C sensors include two Orion Inertial Measurement Units (OIMU's), a Vision Processing Unit (VPU) to process camera images, three barometric altimeters and a single GPS receiver. All of the sensors communicate to one of two Power and Data Units (PDU's). The PDU's multiplex analog and serial data from the sensors and write the data to the Orion Data Network (ODN). The OIMU s write measurement messages directly as onto the ODN, but they are routed through PDU network switches.

King, Ellis T.↗

NASA NTRS2007

Improvements to NASA's Debris Assessment Software

NASA's Debris Assessment Software (DAS) has been substantially revised and expanded. DAS is designed to assist NASA programs in performing orbital debris assessments, as described in NASA s Guidelines and Assessment Procedures for Limiting Orbital Debris. The extensive upgrade of DAS was undertaken to reflect changes in the debris mitigation guidelines, to incorporate recommendations from DAS users, and to take advantage of recent software capabilities for greater user utility. DAS 2.0 includes an updated environment model and enhanced orbital propagators and reentry-survivability models. The ORDEM96 debris environment model has been replaced by ORDEM2000 in DAS 2.0, which is also designed to accept anticipated revisions to the environment definition. Numerous upgrades have also been applied to the assessment of human casualty potential due to reentering debris. Routines derived from the Object Reentry Survival Analysis Tool, Version 6 (ORSAT 6), determine which objects are assessed to survive reentry, and the resulting risk of human casualty is calculated directly based upon the orbital inclination and a future world population database. When evaluating reentry risks, the user may enter up to 200 unique hardware components for each launched object, in up to four nested levels. This last feature allows the software to more accurately model components that are exposed below the initial breakup altitude. The new DAS 2.0 provides an updated set of tools for users to assess their mission s compliance with the NASA Safety Standard and does so with a clear and easy-to-understand interface. The new native Microsoft Windows graphical user interface (GUI) is a vast improvement over the previous DOS-based interface. In the new version, functions are more-clearly laid out, and the GUI includes the standard Windows-style Help functions. The underlying routines within the DAS code are also improved.

Opiela, J.↗

NASA NTRS2014

Lessons Learned in the First Year Operating Software Defined Radios in Space

Operating three unique software defined radios (SDRs) in a space environment aboard the Space Communications and Navigation (SCaN) Testbed for over one year has provided an opportunity to gather knowledge useful for future missions considering using software defined radios. This paper provides recommendations for the development and use of SDRs, and it considers the details of each SDRs approach to software upgrades and operation. After one year, the SCaN Testbed SDRs have operated for over 1000 hours. During this time, the waveforms launched with the SDR were tested on-orbit to assure that they operated in space at the same performance level as on the ground prior to launch to obtain an initial on-orbit performance baseline. A new waveform for each SDR has been developed, implemented, uploaded to the flight system, and tested in the flight environment. Recommendations for SDR-based missions have been gathered from early development through operations. These recommendations will aid future missions to reduce the cost, schedule, and risk of operating SDRs in a space environment. This paper considers the lessons learned as they apply to SDR pre-launch checkout, purchasing space-rated hardware, flexibility in command and telemetry methods, on-orbit diagnostics, use of engineering models to aid future development, and third-party software. Each SDR implements the SCaN Testbed flight computer command and telemetry interface uniquely, allowing comparisons to be drawn. The paper discusses the lessons learned from these three unique implementations, with suggestions on the preferred approach. Also, results are presented showing that it is important to have full system performance knowledge prior to launch to establish better performance baselines in space, requiring additional test applications to be developed pre-launch. Finally, the paper presents the issues encountered with the operation and implementation of new waveforms on each SDR and proposes recommendations to avoid these issues.

radio equipment↗

NASA NTRS2014

Lessons Learned in the First Year Operating Software Defined Radios in Space

Operating three unique software defined radios (SDRs) in a space environment aboard the Space Communications and Navigation (SCaN) Testbed for over one year has provided an opportunity to gather knowledge useful for future missions considering using software defined radios. This paper provides recommendations for the development and use of SDRs, and it considers the details of each SDR's approach to software upgrades and operation. After one year, the SCaN Testbed SDRs have operated for over 1000 hours. During this time, the waveforms launched with the SDR were tested on-orbit to assure that they operated in space at the same performance level as on the ground prior to launch to obtain an initial on-orbit performance baseline. A new waveform for each SDR has been developed, implemented, uploaded to the flight system, and tested in the flight environment. Recommendations for SDR-based missions have been gathered from early development through operations. These recommendations will aid future missions to reduce the cost, schedule, and risk of operating SDRs in a space environment. This paper considers the lessons learned as they apply to SDR pre-launch checkout, purchasing space-rated hardware, flexibility in command and telemetry methods, on-orbit diagnostics, use of engineering models to aid future development, and third-party software. Each SDR implements the SCaN Testbed flight computer command and telemetry interface uniquely, allowing comparisons to be drawn. The paper discusses the lessons learned from these three unique implementations, with suggestions on the preferred approach. Also, results are presented showing that it is important to have full system performance knowledge prior to launch to establish better performance baselines in space, requiring additional test applications to be developed pre-launch. Finally, the paper presents the issues encountered with the operation and implementation of new waveforms on each SDR and proposes recommendations to avoid these issues.

space communication↗

NASA NTRS2005

Testing the Archivas Cluster (Arc) for Ozone Monitoring Instrument (OMI) Scientific Data Storage

The Ozone Monitoring Instrument (OMI) launched on NASA's Aura Spacecraft, the third of the major platforms of the EOS program on July 15,2004. In addition to the long term archive and distribution of the data from OM1 through the Goddard Earth Science Distributed Active Archive Center (GESDAAC), we are evaluating other archive mechanisms that can archive the data in a more immediately available method where it can be used for futher data production and analysis. In 2004, Archivas, Inc. was selected by NASA s Small Business Innovative Research (SBIR) program for the development of their Archivas Cluster (ArC) product. Arc is an online disk based system utilizing self-management and automation on a Linux cluster. Its goal is to produce a low cost solution coupled with the ease of management. The OM1 project is an application partner of the SBIR program, and has deployed a small cluster (5TB) based on the beta Archwas software. We performed extensive testing of the unit using production OM1 data since launch. In 2005, Archivas, Inc. was funded in SBIR Phase II for further development, which will include testing scalability with the deployment of a larger (35TB) cluster at Goddard. We plan to include Arc in the OM1 Team Leader Computing Facility (TLCF) hosting OM1 data for direct access and analysis by the OMI Science Team. This presentation will include a brief technical description of the Archivas Cluster, a summary of the SBIR Phase I beta testing results, and an overview of the OMI ground data processing architecture including its interaction with the Phase II Archivas Cluster and hosting of OMI data for the scientists.

Tilmes, Curt↗