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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRS2007

Digital Multicasting of Multiple Audio Streams

The Mission Control Center Voice Over Internet Protocol (MCC VOIP) system (see figure) comprises hardware and software that effect simultaneous, nearly real-time transmission of as many as 14 different audio streams to authorized listeners via the MCC intranet and/or the Internet. The original version of the MCC VOIP system was conceived to enable flight-support personnel located in offices outside a spacecraft mission control center to monitor audio loops within the mission control center. Different versions of the MCC VOIP system could be used for a variety of public and commercial purposes - for example, to enable members of the general public to monitor one or more NASA audio streams through their home computers, to enable air-traffic supervisors to monitor communication between airline pilots and air-traffic controllers in training, and to monitor conferences among brokers in a stock exchange. At the transmitting end, the audio-distribution process begins with feeding the audio signals to analog-to-digital converters. The resulting digital streams are sent through the MCC intranet, using a user datagram protocol (UDP), to a server that converts them to encrypted data packets. The encrypted data packets are then routed to the personal computers of authorized users by use of multicasting techniques. The total data-processing load on the portion of the system upstream of and including the encryption server is the total load imposed by all of the audio streams being encoded, regardless of the number of the listeners or the number of streams being monitored concurrently by the listeners. The personal computer of a user authorized to listen is equipped with special- purpose MCC audio-player software. When the user launches the program, the user is prompted to provide identification and a password. In one of two access- control provisions, the program is hard-coded to validate the user s identity and password against a list maintained on a domain-controller computer at the MCC. In the other access-control provision, the program verifies that the user is authorized to have access to the audio streams. Once both access-control checks are completed, the audio software presents a graphical display that includes audiostream-selection buttons and volume-control sliders. The user can select all or any subset of the available audio streams and can adjust the volume of each stream independently of that of the other streams. The audio-player program spawns a "read" process for the selected stream(s). The spawned process sends, to the router(s), a "multicast-join" request for the selected streams. The router(s) responds to the request by sending the encrypted multicast packets to the spawned process. The spawned process receives the encrypted multicast packets and sends a decryption packet to audio-driver software. As the volume or muting features are changed by the user, interrupts are sent to the spawned process to change the corresponding attributes sent to the audio-driver software. The total latency of this system - that is, the total time from the origination of the audio signals to generation of sound at a listener s computer - lies between four and six seconds.

Macha, Mitchell↗
NASA NTRS2006

Enhancing Science and Automating Operations using Onboard Autonomy

In this paper, we will describe the evolution of the software from prototype to full time operation onboard Earth Observing One (EO-1). We will quantify the increase in science, decrease in operations cost, and streamlining of operations procedures. Included will be a description of how this software was adapted post-launch to the EO-1 mission, which had very limited computing resources which constrained the autonomy flight software. We will discuss ongoing deployments of this software to the Mars Exploration Rovers and Mars Odyssey Missions as well as a discussion of lessons learned during this project. Finally, we will discuss how the onboard autonomy has been used in conjunction with other satellites and ground sensors to form an autonomous sensor-web to study volcanoes, floods, sea-ice topography, and wild fires. As demonstrated on EO-1, onboard autonomy is a revolutionary advance that will change the operations approach on future NASA missions...

Earth Observing One (EO-1)↗
NASA NTRS2007

Cassini's Test Methodology for Flight Software Verification and Operations

The Cassini spacecraft was launched on 15 October 1997 on a Titan IV-B launch vehicle. The spacecraft is comprised of various subsystems, including the Attitude and Articulation Control Subsystem (AACS). The AACS Flight Software (FSW) and its development has been an ongoing effort, from the design, development and finally operations. As planned, major modifications to certain FSW functions were designed, tested, verified and uploaded during the cruise phase of the mission. Each flight software upload involved extensive verification testing. A standardized FSW testing methodology was used to verify the integrity of the flight software. This paper summarizes the flight software testing methodology used for verifying FSW from pre-launch through the prime mission, with an emphasis on flight experience testing during the first 2.5 years of the prime mission (July 2004 through January 2007).

Cassini Mission↗
NASA NTRS2016

Automation of Flight Software Regression Testing

NASA is developing the Space Launch System (SLS) to be a heavy lift launch vehicle supporting human and scientific exploration beyond earth orbit. SLS will have a common core stage, an upper stage, and different permutations of boosters and fairings to perform various crewed or cargo missions. Marshall Space Flight Center (MSFC) is writing the Flight Software (FSW) that will operate the SLS launch vehicle. The FSW is developed in an incremental manner based on "Agile" software techniques. As the FSW is incrementally developed, testing the functionality of the code needs to be performed continually to ensure that the integrity of the software is maintained. Manually testing the functionality on an ever-growing set of requirements and features is not an efficient solution and therefore needs to be done automatically to ensure testing is comprehensive. To support test automation, a framework for a regression test harness has been developed and used on SLS FSW. The test harness provides a modular design approach that can compile or read in the required information specified by the developer of the test. The modularity provides independence between groups of tests and the ability to add and remove tests without disturbing others. This provides the SLS FSW team a time saving feature that is essential to meeting SLS Program technical and programmatic requirements. During development of SLS FSW, this technique has proved to be a useful tool to ensure all requirements have been tested, and that desired functionality is maintained, as changes occur. It also provides a mechanism for developers to check functionality of the code that they have developed. With this system, automation of regression testing is accomplished through a scheduling tool and/or commit hooks. Key advantages of this test harness capability includes execution support for multiple independent test cases, the ability for developers to specify precisely what they are testing and how, the ability to add automation, and the ability of the harness and cases to be executed continually. This test concept is an approach that can be adapted to support other projects.

Tashakkor, Scott B.↗
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 anomalies (i.e., durring operations) were of interest here, since the goal was to better understand the relationship between critical anomolies during operations and how safety-critical requirements evolve.

requirements↗
DOE OSTI2024

Solar Prize Round 5 Software Track: Abbreviated Final Technical Report

Solar Prize Round 5 launched two simultaneous tracks, the Hardware Track and the Software Track, to introduce software innovations into the Solar Prize for the first time. The primary goal of the prize is to accelerate the development, validation, and commercialization of innovative solar software solutions that will increase the competitiveness of the U.S. solar industry. This is accomplished with three escalating challenges, called the Ready!, Set!, and Go! Contests, where teams work to develop their concept from idea to potentially marketable product in less than one year. Competitors also have the option to compete in a Justice, Equity, Diversity, and Inclusion (JEDI) Contest, which recognizes solutions that enable underserved communities in the United States to overcome systemic solar barriers and share equitably in the societal benefits of solar deployment. The Prize concluded by awarding 2 final winners the Go! Contest prize and a 3rd winner to the JEDI Contest prize in the Software Track, after competing in the prize for a year and demonstrating their success through each phase.

14 SOLAR ENERGY↗
NASA NTRS2016

SLS Flight Software Testing: Using a Modified Agile Software Testing Approach

NASA's Space Launch System (SLS) is an advanced launch vehicle for a new era of exploration beyond earth's orbit (BEO). The world's most powerful rocket, SLS, will launch crews of up to four astronauts in the agency's Orion spacecraft on missions to explore multiple deep-space destinations. Boeing is developing the SLS core stage, including the avionics that will control vehicle during flight. The core stage will be built at NASA's Michoud Assembly Facility (MAF) in New Orleans, LA using state-of-the-art manufacturing equipment. At the same time, the rocket's avionics computer software is being developed here at Marshall Space Flight Center in Huntsville, AL. At Marshall, the Flight and Ground Software division provides comprehensive engineering expertise for development of flight and ground software. Within that division, the Software Systems Engineering Branch's test and verification (T&V) team uses an agile test approach in testing and verification of software. The agile software test method opens the door for regular short sprint release cycles. The idea or basic premise behind the concept of agile software development and testing is that it is iterative and developed incrementally. Agile testing has an iterative development methodology where requirements and solutions evolve through collaboration between cross-functional teams. With testing and development done incrementally, this allows for increased features and enhanced value for releases. This value can be seen throughout the T&V team processes that are documented in various work instructions within the branch. The T&V team produces procedural test results at a higher rate, resolves issues found in software with designers at an earlier stage versus at a later release, and team members gain increased knowledge of the system architecture by interfacing with designers. SLS Flight Software teams want to continue uncovering better ways of developing software in an efficient and project beneficial manner. Through agile testing, there has been increased value through individuals and interactions over processes and tools, improved customer collaboration, and improved responsiveness to changes through controlled planning. The presentation will describe agile testing methodology as taken with the SLS FSW Test and Verification team at Marshall Space Flight Center.

Bolton, Albanie T.↗
DOE OSTI2025

X-Ray Imaging and Spectroscopy Mission

The X-Ray Imaging and Spectroscopy Mission (XRISM) is a joint mission between the Japan Aerospace Exploration Agency (JAXA) and the National Aeronautics and Space Administration (NASA) in collaboration with the European Space Agency (ESA). In addition to the three space agencies, universities and research institutes from Japan, North America, and Europe have joined to contribute to developing satellite and onboard instruments, data-processing software, and the scientific observation program. XRISM is the successor to the ASTRO-H (Hitomi) mission, which ended prematurely in 2016. Its primary science goal is to examine astrophysical problems with precise, high-resolution X-ray spectroscopy. XRISM promises to discover new horizons in X-ray astronomy. It carries a 6 × 6 pixelized X-ray microcalorimeter on the focal plane of an X-ray mirror assembly (Resolve) and a co-aligned X-ray CCD camera (Xtend) that covers the same energy band over a large field of view. XRISM utilizes the Hitomi heritage, but all designs were reviewed. The attitude and orbit control system was improved in hardware and software. The spacecraft was launched from the JAXA Tanegashima Space Center on 2023 September 6 (UTC). During the in-orbit commissioning phase, the onboard components were activated. Although the gate valve protecting the Resolve sensor with a thin beryllium X-ray entrance window was not yet opened, scientific observation started in 2024 February with the planned performance verification observation program. The nominal observation program commenced with the following guest observation program beginning in 2024 September.

Astronomy and AstroPhysics↗
NASA NTRS1976

Evaluation of HAL/S language compilability using SAMSO's Compiler Writing System (CWS)

NASA/Langley is engaged in a program to develop an adaptable guidance and control software concept for spacecraft such as shuttle-launched payloads. It is envisioned that this flight software be written in a higher-order language, such as HAL/S, to facilitate changes or additions. To make this adaptable software transferable to various onboard computers, a compiler writing system capability is necessary. A joint program with the Air Force Space and Missile Systems Organization was initiated to determine if the Compiler Writing System (CWS) owned by the Air Force could be utilized for this purpose. The present study explores the feasibility of including the HAL/S language constructs in CWS and the effort required to implement these constructs. This will determine the compilability of HAL/S using CWS and permit NASA/Langley to identify the HAL/S constructs desired for their applications. The study consisted of comparing the implementation of the Space Programming Language using CWS with the requirements for the implementation of HAL/S. It is the conclusion of the study that CWS already contains many of the language features of HAL/S and that it can be expanded for compiling part or all of HAL/S. It is assumed that persons reading and evaluating this report have a basic familiarity with (1) the principles of compiler construction and operation, and (2) the logical structure and applications characteristics of HAL/S and SPL.

Feliciano, M.↗
NASA NTRS1985

Mathematical models for space shuttle ground systems

Math models are a series of algorithms, comprised of algebraic equations and Boolean Logic. At Kennedy Space Center, math models for the Space Shuttle Systems are performed utilizing the Honeywell 66/80 digital computers, Modcomp II/45 Minicomputers and special purpose hardware simulators (MicroComputers). The Shuttle Ground Operations Simulator operating system provides the language formats, subroutines, queueing schemes, execution modes and support software to write, maintain and execute the models. The ground systems presented consist primarily of the Liquid Oxygen and Liquid Hydrogen Cryogenic Propellant Systems, as well as liquid oxygen External Tank Gaseous Oxygen Vent Hood/Arm and the Vehicle Assembly Building (VAB) High Bay Cells. The purpose of math modeling is to simulate the ground hardware systems and to provide an environment for testing in a benign mode. This capability allows the engineers to check out application software for loading and launching the vehicle, and to verify the Checkout, Control, & Monitor Subsystem within the Launch Processing System. It is also used to train operators and to predict system response and status in various configurations (normal operations, emergency and contingent operations), including untried configurations or those too dangerous to try under real conditions, i.e., failure modes.

Tory, E. G.↗
NASA NTRS1985

Managing computer-controlled operations

A detailed discussion of Launch Processing System Ground Software Production is presented to establish the interrelationships of firing room resource utilization, configuration control, system build operations, and Shuttle data bank management. The production of a test configuration identifier is traced from requirement generation to program development. The challenge of the operational era is to implement fully automated utilities to interface with a resident system build requirements document to eliminate all manual intervention in the system build operations. Automatic update/processing of Shuttle data tapes will enhance operations during multi-flow processing.

Plowden, J. B.↗
NASA NTRS1989

Computer-Aided Software Engineering - An approach to real-time software development

A new software engineering discipline is Computer-Aided Software Engineering (CASE), a technology aimed at automating the software development process. This paper explores the development of CASE technology, particularly in the area of real-time/scientific/engineering software, and a history of CASE is given. The proposed software development environment for the Advanced Launch System (ALS CASE) is described as an example of an advanced software development system for real-time/scientific/engineering (RT/SE) software. The Automated Programming Subsystem of ALS CASE automatically generates executable code and corresponding documentation from a suitably formatted specification of the software requirements. Software requirements are interactively specified in the form of engineering block diagrams. Several demonstrations of the Automated Programming Subsystem are discussed.

Walker, Carrie K.↗
NASA NTRS2020

Command and Control System Automated Testing

To support the National Aeronautics and Space Administration’s (NASA) Space Launch System (SLS) rocket, Kennedy Space Center (KSC) has developed the Spaceport Command and Control System (SCCS) to monitor and control the pre-launch and launch operations. Within SCCS, the Launch Control System (LCS) is designed to allow console engineers to control and monitor the status of the launch and flight hardware, as well as issue commands to ground control systems and launch vehicles. The display software of the LCS is responsible for visualizing the various data that can be received from the hardware and software components of the LCS. Since this system is providing critical information to engineers in the firing room, the visualization of data across the system must be easy to understand, but also reliable and accurate.

Software↗
NASA NTRS2020

Command and Control System Automated Testing

To support the National Aeronautics and Space Administration’s (NASA) Space Launch System (SLS) rocket and the Orion capsule, designed to take humans back to the moon in 2024, Kennedy Space Center (KSC) has developed the Spaceport Command and Control System (SCCS) to monitor and control the launch. Within SCCS, the Launch Control System (LCS) is designed to allow console engineers to control and monitor the status of the launch and flight hardware, as well as issue commands to ground control systems and launch vehicles. The messaging software of LCS is responsible for handling the various data types that can be sent between the hardware and software components of the LCS. Since this system is interacting with numerous devices, controllers, and viewports in real time, the distribution of data across the system must be fast, but also reliable and accurate. To verify the accuracy and reliability of the system, developers on the project have created a set of tests to be performed that covers all operations allowed by the system. Given the extensive Application Programming Interface(API) provided by the messaging software, these unit tests are rather time-consuming and costly (in terms of man-hours) to perform. Therefore, an automated testing framework is used to perform supplemental tests automatically when updates are made to the code base.

Rebecca McFadden↗
NASA NTRS2011

Evolution of Space Shuttle Range Safety (RS) Ascent Flight Envelope Design

Ascent flight envelopes are trajectories that define the normal operating region of a space vehicle s position from liftoff until the end of powered flight. They fulfill part of the RS data requirements imposed by the Air Force s 45th Space Wing (45SW) on space vehicles launching from the Eastern Range (ER) in Florida. The 45SW is chartered to protect the public by minimizing risks associated with the inherent hazards of launching a vehicle into space. NASA s Space Shuttle program has launched 130+ manned missions over a 30 year period from the ER. Ascent envelopes were delivered for each of those missions. The 45SW envelope requirements have remained largely unchanged during this time. However, the methodology and design processes used to generate the envelopes have evolved over the years to support mission changes, maintain high data quality, and reduce costs. The evolution of the Shuttle envelope design has yielded lessons learned that can be applied to future endevours. There have been numerous Shuttle ascent design enhancements over the years that have caused the envelope methodology to evolve. One of these Shuttle improvements was the introduction of onboard flight software changes implemented to improve launch probability. This change impacted the preflight nominal ascent trajectory, which is a key element in the RS envelope design. While the early Shuttle nominal trajectories were designed preflight using a representative monthly mean wind, the new software changes involved designing a nominal ascent trajectory on launch day using real-time winds. Because the actual nominal trajectory position was not known until launch day, the envelope analysis had to be customized to account for this nominal trajectory variation in addition to the other envelope components.

Brewer, Joan D.↗
NASA NTRS1990

IEEE/AIAA/NASA Digital Avionics Systems Conference, 9th, Virginia Beach, VA, Oct. 15-18, 1990, Proceedings

The present conference on digital avionics discusses vehicle-management systems, spacecraft avionics, special vehicle avionics, communication/navigation/identification systems, software qualification and quality assurance, launch-vehicle avionics, Ada applications, sensor and signal processing, general aviation avionics, automated software development, design-for-testability techniques, and avionics-software engineering. Also discussed are optical technology and systems, modular avionics, fault-tolerant avionics, commercial avionics, space systems, data buses, crew-station technology, embedded processors and operating systems, AI and expert systems, data links, and pilot/vehicle interfaces.

Source record↗
NASA NTRS2008

Volume Averaged Height Integrated Radar Reflectivity (VAHIRR) Cost-Benefit Analysis

Lightning Launch Commit Criteria (LLCC) are designed to prevent space launch vehicles from flight through environments conducive to natural or triggered lightning and are used for all U.S. government and commercial launches at government and civilian ranges. They are maintained by a committee known as the NASA/USAF Lightning Advisory Panel (LAP). The previous LLCC for anvil cloud, meant to avoid triggered lightning, have been shown to be overly restrictive. Some of these rules have had such high safety margins that they prohibited flight under conditions that are now thought to be safe 90% of the time, leading to costly launch delays and scrubs. The LLCC for anvil clouds was upgraded in the summer of 2005 to incorporate results from the Airborne Field Mill (ABFM) experiment at the Eastern Range (ER). Numerous combinations of parameters were considered to develop the best correlation of operational weather observations to in-cloud electric fields capable of rocket triggered lightning in anvil clouds. The Volume Averaged Height Integrated Radar Reflectivity (VAHIRR) was the best metric found. Dr. Harry Koons of Aerospace Corporation conducted a risk analysis of the VAHIRR product. The results indicated that the LLCC based on the VAHIRR product would pose a negligible risk of flying through hazardous electric fields. Based on these findings, the Kennedy Space Center Weather Office is considering seeking funding for development of an automated VAHIRR algorithm for the new ER 45th Weather Squadron (45 WS) RadTec 431250 weather radar and Weather Surveillance Radar-1988 Doppler (WSR-88D) radars. Before developing an automated algorithm, the Applied Meteorology Unit (AMU) was tasked to determine the frequency with which VAHIRR would have allowed a launch to safely proceed during weather conditions otherwise deemed "red" by the Launch Weather Officer. To do this, the AMU manually calculated VAHIRR values based on candidate cases from past launches with known anvil cloud LLCC violations. An automated algorithm may be developed if the analyses from past launches show VAHIRR would have provided a significant cost benefit by allowing a launch to proceed. The 45 WS at the ER and 30th Weather Squadron (30 WS) at the Western Range provided the AMU with launch weather summaries from past launches that were impacted by LLCC. The 45 WS provided summaries from 14 launch attempts and the 30 WS fkom 5. The launch attempts occurred between December 2001 and June 2007. These summaries helped the AMU determine when the LLCC were "red" due to anvil cloud. The AMU collected WSR-88D radar reflectivity, cloud-to-ground lightning strikes, soundings and satellite imagery. The AMU used step-by-step instructions for calculating VAHIRR manually as provided by the 45 WS. These instructions were used for all of the candidate cases when anvil cloud caused an LLCC violation identified in the launch weather summaries. The AMU evaluated several software programs capable of visualizing radar data so that VAHIRR could be calculated and chose GR2Analyst from Gibson Ridge Software, LLC. Data availability and lack of detail from some launch weather summaries permitted analysis of six launch attempts from the ER and none from the WR. The AMU did not take into account whether or not other weather LCC violations were occurring at the same time as the anvil cloud LLCC since the goal of this task was to determine how often VAHIRR provided relief to the anvil cloud LLCC at any time during several previous launch attempts. Therefore, in the statistics presented in this report, it is possible that even though VAHIRR provided relief to the anvil cloud LLCC, other weather LCC could have been violated not permitting the launch to proceed. The results of this cost-benefit analysis indicated VAHIRR provided relief from the anvil cloud LLCC between about 15% and 18% of the time for varying 5-minute time periods based on summaries fkom six launch attempts and would have allowed launch to proceed that were otherwise "NO GO" due to the anvil cloud LLCC if the T-0 time occurred during the anvil cloud LLCC violations.

Bauman, William H., III↗