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 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS2018

Utilizing Testing Frameworks for Launch Control Systems Continuous Integration

Command and control software is an integral part of the launch procedure. The most important part of this type of software is its ability to communicate well with the user and relay information in a correctly formatted way such that the user can understand the data. There is a tool that aides the communication between the different parts of the system, and effectively, the user. This instrument is capable of taking several complex values and ensuring that they are correctly sorted into their distinctive message values and distributed properly among the different facets of the system. This tool will easily translate and publish the data inside of messages in the system to something that is readable and understandable. The tool also allows for transmission of the recorded data to the user, effectively ensuring the communication between different components of the system. As well as keeping track of messages and ensuring that the information contained within each of them reaches the correct location, this tool has the ability to keep track of its own statistics and determine how many messages passed in were erroneous and how many were successfully transmitted. It is able to check and see what the total message failure count is when an invalid message is given, as well as the number of different messages and their respective types passed into the tool. This tool is of great value to the new Space Launch System (SLS). As such, the tool must be thoroughly tested with test cases that, although improbable, are possible, where the tool may not function properly. Testing an interface this complex is necessary to ensure mission safety and create unlikely scenarios where the tool would work as intended, and stretch its limits to test that even under the most uncommon conditions it would still continue to function. This software will be an important part of the control system for the newest spacecraft which will fly deeper into space than humans have ever travelled. It will fly beyond the moon, into deep space to Mars and perhaps set the groundwork for a manned mission even further to create more opportunities for interplanetary and even interstellar travel by humans. This mission relies heavily on software and hardware to ensure the safety of the humans that will be on board and therefore must be checked, exhausting each and every different situation, such that there is not a doubt surrounding the well-being of the humans aboard the rocket. That is why testing is such an important part of the mission. It provides evidence that the systems aboard the rocket and on the launch pad are safe.

Unit Testing↗
NASA NTRS2010

The Latest Space-Borne Observations of TGFs from Fermi-GBM

The Gamma-ray Burst Monitor (GBM) on the Fermi Gamma-ray Space Telescope Observatory (Fermi) is detecting about two TGFs per week. This rate has increased by a factor of approx.eight since launch when flight software was uploaded to the spacecraft in November 2009 in order to increase the sensitivity of GBM to TGFs. Weaker, un-triggered TGFs are now also being observed about once per day over selected low-latitude regions Americas. The high efficiency and time resolution (2 s) of GBM allows temporal features to be resolved so that some insight may be gained on the origin and transport of the gamma-ray photons through the atmosphere. TGFs are observed to be shorter than previously thought, with an average duration of approx.100 micro-s. The absolute times of TGFs are known to approx.10 micro-s, allowing accurate correlations of TGFs with lightning networks and other lightning-related phenomena. The events are observed in the thick bismuth germanate (BGO) scintillation detectors of GBM with photon energies above 40 MeV. Other new results on the temporal and spectral characteristics of TGFs will be presented, along with properties of several electron-positron TGF events that have been identified.

Fishman, Gerald J.↗
NASA NTRS2019

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↗
NASA NTRS1988

Launch operations efficiency

The paper discusses launch operations from a program perspective. Launch operations cost is a significant part of program cost. New approaches to launch operations, integrated with lessons learned, have the potential to increase safety and reliability as well as reduce cost. Operational efficiency must be an initial program goal. Design technology and management philosophy must be implemented early to ensure operational cost goals. Manufacturing cost and launch cost are related to operational efficiency. True program savings can be realized through implementation of launch operations cost saving approaches which do not correspondingly increase cost in other program areas such as manufacturing and software development and maintenance. Launch rate is a key factor in the cost/flight analysis and the determination of launch operations efficiency goals.

Diloreto, Clem↗
NASA NTRS2015

2nd Generation QUATARA Flight Computer Project

Single core flight computer boards have been designed, developed, and tested (DD&T) to be flown in small satellites for the last few years. In this project, a prototype flight computer will be designed as a distributed multi-core system containing four microprocessors running code in parallel. This flight computer will be capable of performing multiple computationally intensive tasks such as processing digital and/or analog data, controlling actuator systems, managing cameras, operating robotic manipulators and transmitting/receiving from/to a ground station. In addition, this flight computer will be designed to be fault tolerant by creating both a robust physical hardware connection and by using a software voting scheme to determine the processor's performance. This voting scheme will leverage on the work done for the Space Launch System (SLS) flight software. The prototype flight computer will be constructed with Commercial Off-The-Shelf (COTS) components which are estimated to survive for two years in a low-Earth orbit.

Falker, Jay↗
NASA NTRS1991

Autonomous Guidance, Navigation and Control

The NASA Autonomous Guidance, Navigation and Control (GN&C) Bridging program is reviewed to demonstrate the program plan and GN&C systems for the Space Shuttle. The ascent CN&C system is described in terms of elements such as the general-purpose digital computers, sensors for the navigation subsystem, the guidance-system software, and the flight-control subsystem. Balloon-based and lidar wind soundings are used for operations assessment on the day of launch, and the guidance software is based on dedicated units for atmospheric powered flight, vacuum powered flight, and abort-specific situations. Optimization of the flight trajectories is discussed, and flight-control responses are illustrated for wavelengths of 500-6000 m. Alternate sensors are used for load relief, and adaptive GN&C systems based on alternate gain synthesis are used for systems failures.

Bordano, A. J.↗
NASA NTRSDate not supplied

Lessons Learned on Mega-Constellation Deployments and Impact to Space Domain Awareness

The breakneck expansion of multi-payload launches in low Earth orbit (LEO) has seen significant escalation over the last three years in the Space Domain Awareness (SDA) enterprise. The uptick in satellite deployment frequency, gradation of Mega-constellation deployments utilizing electric propulsion, and surge in metric observation density from the Space Surveillance Network (SSN) have imposed major system enhancements to ensure spaceflight safety. Beginning with the launch phase, new tactics, software, and procedures have been developed over the last few years to optimize the tasking of the SSN and ensure custody of all recently launched satellites that are added to the space catalog. Ensuring appropriate tasking levels were pivotal during the satellite separation phase, which necessitated updates to the mission systems for improved delineation between clustered satellites in a short window of time. The improved incorporation of utilizing owner operator provided ephemeris coupled with critical code improvements have now revolutionized how we maintain custody of earth orbiting objects. The exponential population growth of low-Earth orbiting satellites have also increased the quantity of Conjunction Data Messages sent out to partners such as the Trajectory Operations Group (TOPO) in Johnson Space Center. We will discuss the need for continued collaboration between the National Aeronautics and Space Administration (NASA) and other Mega-Constellation Satellite Operators to safeguard Human Space Flight operations. Lastly, we will discuss the increase in reentry reporting for satellites falling back to Earth’s atmosphere, and the challenges associated with these events.

Christian C Ramos↗
NASA NTRSDate not supplied

Lessons Learned on Mega-Constellation Deployments and Impact to Space Domain Awareness

The breakneck expansion of multi-payload launches in low Earth orbit (LEO) has seen significant escalation over the last three years in the Space Domain Awareness (SDA) enterprise. The uptick in satellite deployment frequency, gradation of mega-constellation deployments utilizing electric propulsion, and surge in metric observation density from the Space Surveillance Network (SSN) have driven major system enhancements to ensure spaceflight safety. Beginning with the launch phase, new tactics, software, and procedures have been developed over the last few years to optimize the tasking of the SSN and ensure custody of all recently launched satellites that are added to the space catalog. Ensuring appropriate tasking levels were pivotal during the satellite separation phase, which necessitated updates to the mission systems for improved delineation between clustered satellites in a short window of time. The improved incorporation of utilizing satellite owner/operator-provided ephemeris coupled with critical code improvements have revolutionized how we maintain custody of Earth orbiting objects. The exponential population growth of Low-Earth orbiting satellites have also increased the quantity of Conjunction Data Messages sent out to partners such as the Trajectory Operations Group (TOPO) in Johnson Space Center. We will discuss the need for continued collaboration between the National Aeronautics and Space Administration (NASA) and other mega-constellation satellite operators to safeguard human spaceflight operations. Lastly, we will discuss how mega-constellations are driving best practices for safe operations across the space community.

Christian Ramos↗
NASA NTRS2008

Virtual Satellite

Virtual Satellite (VirtualSat) is a computer program that creates an environment that facilitates the development, verification, and validation of flight software for a single spacecraft or for multiple spacecraft flying in formation. In this environment, enhanced functionality and autonomy of navigation, guidance, and control systems of a spacecraft are provided by a virtual satellite that is, a computational model that simulates the dynamic behavior of the spacecraft. Within this environment, it is possible to execute any associated software, the development of which could benefit from knowledge of, and possible interaction (typically, exchange of data) with, the virtual satellite. Examples of associated software include programs for simulating spacecraft power and thermal- management systems. This environment is independent of the flight hardware that will eventually host the flight software, making it possible to develop the software simultaneously with, or even before, the hardware is delivered. Optionally, by use of interfaces included in VirtualSat, hardware can be used instead of simulated. The flight software, coded in the C or C++ programming language, is compilable and loadable into VirtualSat without any special modifications. Thus, VirtualSat can serve as a relatively inexpensive software test-bed for development test, integration, and post-launch maintenance of spacecraft flight software.

Hammrs, Stephan R.↗
NASA NTRS2016

Modeling in the State Flow Environment to Support Launch Vehicle Verification Testing for Mission and Fault Management Algorithms in the NASA Space Launch System

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.

Trevino, Luis↗
NASA NTRS1997

Bantam System Technology Project Ground System Requirements Document

The Low Cost Booster Project (LCBP), also known as Bantam, is an element of the Advanced Space Transportation Program focused on Low Cost Booster Technologies. During FY 99 flight demonstrations are planned to demonstrate the feasibility of producing a booster capable of inserting a 150 kg payload into low earth orbit. The ground support system is an element of the full launch system. The ground support system provides for integration of the payload with the launch vehicle, preparation of the vehicle for launch (including maintenance, integration and test of the vehicle flight software), monitor and control of the launch sequence, range safety during launch, and collection of telemetry during the flight up to payload release. The ground support system is intended to make the maximum possible use of Government Off-the-Shelf (GOTS) or Commercial Off-the-Shelf (COTS) hardware and software to obtain the best value in terms of development operations support and ultimate life cycle cost for the launch system.

Moon, J. M.↗
NASA NTRSDate not supplied

Autonomous Navigation, Guidance, and Control Software in a Low SWaP Box

Onboard autonomy is a necessity for responsive space operations. Autonomous navigation, guidance, and control (NGC) enables space missions to reduce their dependence on high demand ground assets and costly ground personnel. It also allows for in-situ decision making and higher return on mission data. A flight software and hardware system providing this capability, called “autoNGC,” is currently being developed at NASA Goddard Space Flight Center for infusion into multiple future missions. The autoNGC flight software is built on the plug-and-play architecture of the core Flight System (cFS) consisting of the standard cFS apps and newly developed autoNGC interface apps and libraries. The various apps cooperate through communication over the message-based software bus. With the plug-and-play architecture of autoNGC, cFS apps can easily be added and replaced to meet the needs of different missions, even after launch. The first flight software release of autoNGC is targeted for Summer 2024 to provide autonomous navigation at the Moon and beyond. It can perform sensor fusion of multiple measurement types including pseudo-range from a Global Navigation Satellite System (GNSS) receiver (including weak signal), 1-way and 2-way range and Doppler from ground stations (i.e., direct to Earth (DTE)), bearing and range from optical camera images, and accelerometer data. Accurate onboard navigation and timing is obtained through the Goddard Enhanced Onboard Navigation System (GEONS) software library which fuses different measurement types through an extended Kalman filter (EKF) framework. Optical measurements that are ingested in GEONS are first extracted from optical images by the cFS Goddard Image Analysis and Navigation Tool (cGIANT) app. If the imaged body is far enough away that it appears as a pixel or cluster of pixels, then bearing angles to the body centroid can be provided. If the body is close enough and the shape is known coarsely, then bearing angles and range to the body centroid can be derived from the limb. Bearing angles to individual surface features can also be extracted (i.e., terrain relative navigation (TRN)). Onboard guidance and control capabilities are being developed for a future release to perform autonomous station-keeping and trajectory correction maneuvers in multiple orbital regimes. Capabilities to enable distributed systems missions and constellations, such as crosslink measurements, and onboard time management are being developed as well. The first hardware implementation of autoNGC is a minimal size, weight, and power (SWaP) design allowing for inclusion into CubeSats and SmallSat-size buses. Advancements in miniaturized space processors, such as the SpaceCube 3.0 Mini and the SpaceCube Mini-Z are utilized for low SWaP while maintaining a high level of performance. The current enclosure design is 12 cm x 17 cm x 13.5 cm. The box mass is expected to be less than 2 kg, and the nominal power is 21 W. In order to accommodate a wide range of missions, the hardware interfaces are designed for flexibility with a variety of sensor inputs. Through comprehensive testing in the software-in-the-loop, processor-in-the-loop, and hardware-in-the-loop test beds that are concurrently being developed, autoNGC is expected to achieve TRL 6 by late 2024.

Sun Hur-Diaz↗
NASA NTRS2012

Reliability, Maintainability, and Availability: Consideration During the Design Phase in Ground Systems to Ensure Successful Launch Support

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

Gillespie, Amanda M.↗
NASA NTRS2001

Evolution of safety-critical requirements post-launch

This paper reports the results of a small study of requirements changes to the onboard software of three spacecraft subsequent to launch. Only those requirement changes that resulted from post-launch anoma-lies (i.e., during operations) were of interest here, since the goal was to better understand the relation-ship between critical anomalies during operations and how safety-critical requirements evolve. The results of the study were surprising in that anomaly-driven, post-launch requirements changes were rarely due to previous requirements having been incorrect. Instead, changes involved new requirements (1) for the software to handle rare events or (2) for the software to compensate for hardware failures or limitations. The prevalence of new requirements as a result of post-launch anomalies suggests a need for increased requirements-engineering support of maintenance activities in these systems. The results also confirm both the difficulty and the benefits of pursuing requirements completeness, especially in terms of fault tolerance, during development of critical systems.

Software requirements↗
NASA NTRS2014

Adaptive Augmenting Control Flight Characterization Experiment on an F/A-18

The NASA Marshall Space Flight Center (MSFC) Flight Mechanics and Analysis Division developed an Adaptive Augmenting Control (AAC) algorithm for launch vehicles that improves robustness and performance by adapting an otherwise welltuned classical control algorithm to unexpected environments or variations in vehicle dynamics. This AAC algorithm is currently part of the baseline design for the SLS Flight Control System (FCS), but prior to this series of research flights it was the only component of the autopilot design that had not been flight tested. The Space Launch System (SLS) flight software prototype, including the adaptive component, was recently tested on a piloted aircraft at Dryden Flight Research Center (DFRC) which has the capability to achieve a high level of dynamic similarity to a launch vehicle. Scenarios for the flight test campaign were designed specifically to evaluate the AAC algorithm to ensure that it is able to achieve the expected performance improvements with no adverse impacts in nominal or nearnominal scenarios. Having completed the recent series of flight characterization experiments on DFRC's F/A-18, the AAC algorithm's capability, robustness, and reproducibility, have been successfully demonstrated. Thus, the entire SLS control architecture has been successfully flight tested in a relevant environment. This has increased NASA's confidence that the autopilot design is ready to fly on the SLS Block I vehicle and will exceed the performance of previous architectures.

VanZwieten, Tannen S.↗
NASA NTRS1999

Rocket Noise Prediction Program

A comprehensive, automated, and user-friendly software program was developed to predict the noise and ignition over-pressure environment generated during the launch of a rocket. The software allows for interactive modification of various parameters affecting the generated noise environment. Predictions can be made for different launch scenarios and a variety of vehicle and launch mount configurations. Moreover, predictions can be made for both near-field and far-field locations on the ground and any position on the vehicle. Multiple engine and fuel combinations can be addressed, and duct geometry can be incorporated efficiently. Applications in structural design are addressed.

Margasahayam, Ravi↗
NASA NTRS2021

Case Studies in Verifying Spacecraft Autonomy

Spacecraft, operating with a time-to-effect faster than human command response, or with absent or delayed communication, have depended on autonomy. It is likely that this reliance will continue, and increase further in future missions. Spacecraft autonomy is used when operator intervention is not available or feasible, or when dynamic aspects of a spacecraft situation cannot be predicted in advance. This paper provides case studies of several successfully verified autonomous software systems across multiple spacecraft, flight phases (launch, transit, entry and landing, science utilization), and software classifications, and can serve as examples to future missions in methods of successfully assuring spacecraft autonomy.

Johnson, Stephen B.↗
NASA NTRS2002

Libration Orbit Mission Design: Applications of Numerical & Dynamical Methods

Sun-Earth libration point orbits serve as excellent locations for scientific investigations. These orbits are often selected to minimize environmental disturbances and maximize observing efficiency. Trajectory design in support of libration orbits is ever more challenging as more complex missions are envisioned in the next decade. Trajectory design software must be further enabled to incorporate better understanding of the libration orbit solution space and thus improve the efficiency and expand the capabilities of current approaches. The Goddard Space Flight Center (GSFC) is currently supporting multiple libration missions. This end-to-end support consists of mission operations, trajectory design, and control. It also includes algorithm and software development. The recently launched Microwave Anisotropy Probe (MAP) and upcoming James Webb Space Telescope (JWST) and Constellation-X missions are examples of the use of improved numerical methods for attaining constrained orbital parameters and controlling their dynamical evolution at the collinear libration points. This paper presents a history of libration point missions, a brief description of the numerical and dynamical design techniques including software used, and a sample of future GSFC mission designs.

Bauer, Frank↗