AS-503 post launch software assessment
Saturn launch computer complex software problems and anomalies during countdown of AS-503
Source record↗
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.
Empirical analysis of safety - critical software anomalies post-launch
Explore the source record for details and available documents.
anomalies post-launch software safety↗
Launch Control Systems: Moving Towards a Scalable, Universal Platform for Future Space Endeavors
The redirection of NASA away from the Constellation program calls for heavy reliance on commercial launch vehicles for the near future in order to reduce costs and shift focus to research and long term space exploration. To support them, NASA will renovate Kennedy Space Center's launch facilities and make them available for commercial use. However, NASA's current launch software is deeply connected with the now-retired Space Shuttle and is otherwise not massively compatible. Therefore, a new Launch Control System must be designed that is adaptable to a variety of different launch protocols and vehicles. This paper exposits some of the features and advantages of the new system both from the perspective of the software developers and the launch engineers.
Sun, Jonathan↗
Dynamic IT Security Database and Analytics for Launch Control Systems Software
During the Summer 2020 session, I worked with intern Destani S. Van Arsdalen of EGS Software. Together, we co-created a tool to aid the dynamic investigation, updated over time,of the security compliance of LCS COTS and open source software. We originally planned touse spreadsheet software for management and analysis, but through this exploratoryproject, chose to use Python and JSON after receiving feedback on our project’s current anddesired capabilities at that time.At first, the project was solely designed to help on-board new COTS software, based on aquestionnaire that could be filled out for each software package. This, combined with usingthe spreadsheet application’s web-query capabilities to fetch information from the NVD,allowed presentation and analytics cells to automatically populate as elements of themanually-filled questionnaire changed. While this system was promising, we decided tochange technologies for a few reasons. In the spreadsheet, single cells could not hold complexdata like arrays and objects. The automatic population of cells and dynamic updates made itdifficult to manage and add new features. And finally, it had limited extensibility sinceadding new software required significant understanding of how both the spreadsheet wasconstructed, and the more obscure, proprietary scripting languages packaged with it.The pivot to a standard computer science database language of JSON, aided by thescripting capabilities of Python, greatly helped to improve the project’s functionality. First,and most importantly, the script’s import and analysis of database data is easilyreproducible. Additional data analysis can be modularly added without requiringmodification of the script and is capable of routine scheduling. The revised process can besplit into three parts. First, the conversion of LCS asset and software documentation into theJSON hierarchical database format. Second, the merging of this database with the NVD,forming a new data structure, using CPEs of the CVE object as a linking element betweenthem. And third, the automatically performed analytics and analysis of the combined data,in a modular and extensible format, to produce better informed business decisions. The outputted graphs, for example, are automatically generated by the Python script inconnection with the combined database. This allows updated graphs and any analytics to be re-rendered automatically following updates to the LCS’s initial asset documentation. Afinal report can then be programmatically and easily constructed from these sources to allow fully reproducible metrics for heavily evidenced risk management decisions.
it↗
Estimating Software Reliability for Space Launch Vehicles in Probabilistic Risk Assessment (PRA)
It is acutely recognized in the Probabilistic Risk assessment (PRA) field that software plays a defining role in overall system reliability for all modern systems across a wide variety of industries. Regardless if the software is embedded firmware for working components or elements, part of a Human-Machine-Interface, or automated command and control logic, the success of the software to fulfill its function under nominal and off-nominal environments will be a dominant contributor to system reliability. It is also recognized that software reliability prediction and estimation is one of the more challenging and questionable aspects of any PRA or system analyses due to the nature of software and its integration with physics based systems. Irrespective of this dichotomy, any incorporation of software reliability methods requires that the contributions are accountable, quantitative, and tractable. This paper provides a brief overview of software reliability methods, establishes some minimum requirements that the methods should incorporate for completeness, and provides a logic structure for applying software reliability. Model resolution will be discussed that supports current testing plans and trade studies. We will provide initial recommendations for use in the NASA PRA and present a future dynamic option for software and PRA. Space Launch Vehicle Software is recognized to be reliable in static conditions, yet relatively vulnerable to a set of failure modes in changing environments/flight phases. Two quantitative methods were chosen to incorporate software reliability into a Space Launch Vehicle PRA accounting for phase adjustments. One method predicts latent software failure using statistical methods, and the second provides estimates of coding errors and software operating system failures based on test and historical data, respectively. Software uncertainty will also be discussed. We determined that recommendations for PRA software reliability should be modeled at the software module level where multiple software components compose a module and combinations of the software architecture can lead to a functional failure.
Novack, Steven↗
Estimating Software Reliability for Space Launch Vehicles in Probabilistic Risk Assessment (PRA)
It is acutely recognized in the Probabilistic Risk Assessment (PRA) field that software plays a defining role in overall system reliability for all modern systems across a wide variety of industries. Regardless of whether the software is embedded firmware for working components or elements, part of a Human-Machine-Interface, or automated command and control logic, the success of the software to fulfill its function under nominal and off-nominal environments will be a dominant contributor to system reliability. It is also recognized that software reliability prediction and estimation is one of the more challenging and questionable aspects of any PRA or system analyses due to the nature of software and its integration with physics based systems. Irrespective of this dichotomy, any incorporation of software reliability methods requires that the contributions are accountable, quantitative, and tractable. This paper provides a brief overview of software reliability methods, establishes some minimum requirements that the methods should incorporate for completeness, and provides a logic structure for applying software reliability. Model resolution will be discussed that supports current testing plans and trade studies. We will provide initial recommendations for use in the National Aeronautics and Space Administration (NASA) PRA and present a future dynamic option for software and PRA. Space Launch Vehicle software is recognized to be reliable in static conditions, yet relatively vulnerable to a set of failure modes in changing environments/flight phases. Two quantitative methods were chosen to incorporate software reliability into a Space Launch Vehicle PRA accounting for phase adjustments. One method predicts latent software failure using statistical methods, and the second provides estimates of coding errors and software operating system failures based on test and historical data. Software uncertainty will also be discussed. It is determined that recommendations for PRA software reliability should be modeled at the software module level where multiple software components compose a module and combinations of the software architecture can lead to a functional failure.
Steven D. Novack↗
Launch Control System Software Development System Automation Testing
The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administration's (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This system requires high quality testing that will measure and test the capabilities of the system. For the past two years, the Exploration and Operations Division at Kennedy Space Center (KSC) has assigned a group including interns and full-time engineers to develop automated tests to save the project time and money. The team worked on automating the testing process for the SCCS GUI that would use streamed simulated data from the testing servers to produce data, plots, statuses, etc. to the GUI. The software used to develop automated tests included an automated testing framework and an automation library. The automated testing framework has a tabular-style syntax, which means the functionality of a line of code must have the appropriate number of tabs for the line to function as intended. The header section contains either paths to custom resources or the names of libraries being used. The automation library contains functionality to automate anything that appears on a desired screen with the use of image recognition software to detect and control GUI components. The data section contains any data values strictly created for the current testing file. The body section holds the tests that are being run. The function section can include any number of functions that may be used by the current testing file or any other file that resources it. The resources and body section are required for all test files; the data and function sections can be left empty if the data values and functions being used are from a resourced library or another file. To help equip the automation team with better tools, the Project Lead of the Automated Testing Team, Jason Kapusta, assigned the task to install and train an optical character recognition (OCR) tool to Brandon Echols, a fellow intern, and I. The purpose of the OCR tool is to analyze an image and find the coordinates of any group of text. Some issues that arose while installing the OCR tool included the absence of certain libraries needed to train the tool and an outdated software version. We eventually resolved the issues and successfully installed the OCR tool. Training the tool required many images and different fonts and sizes, but in the end the tool learned to accurately decipher the text in the images and their coordinates. The OCR tool produced a file that contained significant metadata for each section of text, but only the text and coordinates of the text was required for our purpose. The team made a script to parse the information we wanted from the OCR file to a different file that would be used by automation functions within the automated framework. Since a majority of development and testing for the automated test cases for the GUI in question has been done using live simulated data on the workstations at the Launch Control Center (LCC), a large amount of progress has been made. As of this writing, about 60% of all of automated testing has been implemented. Additionally, the OCR tool will help make our automated tests more robust due to the tool's text recognition being highly scalable to different text fonts and text sizes. Soon we will have the whole test system automated, allowing for more full-time engineers working on development projects.
Automation↗
Considerations for Using Autonomous Flight Termination Software in Crewed Launch Vehicles
Autonomous flight termination systems (AFTS) are being progressively employed onboard launch vehicles to replace ground personnel and infrastructure needed to terminate flight or destruct the vehicle should an anomaly occur. This automation uses on-board real-time data and encoded logic to determine if the flight should be self-terminated. For uncrewed launch vehicles, FTS systems are required to protect the public and governed by the United States Space Force (USSF). For crewed missions, NASA must augment range AFTS requirements for crew safety and certify each flight according to human rating standards, thus adding unique requirements for reuse of software originally intended for uncrewed missions. This bulletin summarizes new information relating to AFTS to raise awareness of key distinctions, summarize considerations and outline best practices for incorporating AFTS into human-rated systems.
Avionics↗
Real time space vehicle and ground support systems software simulator for launch programs checkout
Real time simulation of space vehicle and ground support equipment by digital computer for launch programs checkout
Brown, P. A.↗
Command and Control Software Development
As NASA’s role in spaceflight operations change, so too does its design priorities. NASA’s flagship venture, the Space Launch System (SLS), is being created primarily to explore deep space. While commercial partners conduct low Earth orbit resupplies, tests, and even transportation of astronauts, NASA can divert more resources to more exciting projects - going back to the moon, or onwards to Mars. In the short term, this goal manifests in the upcoming Exploration Mission-1 (EM-1) test of the SLS, slated for as early as 2019. SLS, with the Orion capsule, will travel farther than any human-rated spacecraft has gone before. As the most powerful launch vehicle ever created, SLS requires many new innovations to ensure mission success. One such technology is the launch control software, which is the focus of this internship. The SLS launch control software is composed of many functions, all of which require rigorous testing to meet the standard of life-critical code. To facilitate easier testing, the first project I undertook was to customize the open-source tool Wireshark to the software team’s needs. Wireshark is a network protocol analyzer that can take in information about custom information packets. The launch control software will have several protocols that are custom to NASA. I ensured that all necessary component files were the correct file type and in the correct structure for Wireshark to compile. Having allowed Wireshark access to understand custom NASA data packets, testers of the launch control software will be able to find anomalies easier.
Wang, Zhengdong↗
NASA Tech Briefs, June 2003
Topics covered include: Nulling Infrared Radiometer for Measuring Temperature; The Ames Power Monitoring System; Hot Films on Ceramic Substrates for Measuring Skin Friction; Probe Without Moving Parts Measures Flow Angle; Detecting Conductive Liquid Leaking from Nonconductive Pipe; Adaptive Suppression of Noise in Voice Communications; High-Performance Solid-State W-Band Power Amplifiers; Microbatteries for Combinatorial Studies of Conventional Lithium-Ion Batteries; Correcting for Beam Aberrations in a Beam-Waveguide Antenna; Advanced Rainbow Solar Photovoltaic Arrays; Metal Side Reflectors for Trapping Light in QWIPs; Software for Collaborative Engineering of Launch Rockets; Software Assists in Extensive Environmental Auditing; Software Supports Distributed Operations via the Internet; Software Estimates Costs of Testing Rocket Engines; yourSky: Custom Sky-Image Mosaics via the Internet; Software for Managing Inventory of Flight Hardware; Lower-Conductivity Thermal-Barrier Coatings; Process for Smoothing an Si Substrate after Etching of SiO2; Flexible Composite-Material Pressure Vessel; Treatment to Destroy Chlorohydrocarbon Liquids in the Ground; Noncircular Cross Sections Could Enhance Mixing in Sprays; Small, Untethered, Mobile Roots for Inspecting Gas Pipes; Paint-Overspray Catcher; Preparation of Regular Specimens for Atom Probes; Inverse Tomo-Lithography for Making Microscopic 3D Parts; Predicting and Preventing Incipient Flameout in Combustors; MEMS-Based Piezoelectric/Electrostatic Inchworm Actuator; Metallized Capillaries as Probes for Raman Spectroscopy; Adaptation of Mesoscale Weather Models to Local Forecasting; Aerodynamic Design using Neural Networks; Combining Multiple Gyroscope Outputs for Increased Accuracy; and Improved Collision-Detection Method for Robotic Manipulator.
Source record↗
Adapting ODC for Empirical Evaluation of Pre-Launch Anomalies
This slide presentation reviews the concept of using Orthogonal Defect Classification (ODC) to identify pre-launch anomalies in software. The goals of this work are: (1) To characterize pre-launch software anomalies, using data from multiple spacecraft projects, by means of a defect-analysis technology, Orthogonal Defect Classification (ODC). (2) To support transfer of ODC to NASA projects through applications and demonstrations. Approach: Analyzed anomaly data using adaptation of Orthogonal Defect Classification (ODC) method. This project has adapted ODC for NASA use and applied to NASA projects.
defect analysis↗
The Application of Software Safety to the Constellation Program Launch Control System
The application of software safety practices on the LCS project resulted in the successful implementation of the NASA Software Safety Standard NASA-STD-8719.138 and CxP software safety requirements. The GOP-GEN-GSW-011 Hazard Report was the first report developed at KSC to identify software hazard causes and their controls. This approach can be applied to similar large software - intensive systems where loss of control can lead to a hazard.
Kania, James↗
Software for Collaborative Engineering of Launch Rockets
The Rocket Evaluation and Cost Integration for Propulsion and Engineering software enables collaborative computing with automated exchange of information in the design and analysis of launch rockets and other complex systems. RECIPE can interact with and incorporate a variety of programs, including legacy codes, that model aspects of a system from the perspectives of different technological disciplines (e.g., aerodynamics, structures, propulsion, trajectory, aeroheating, controls, and operations) and that are used by different engineers on different computers running different operating systems. RECIPE consists mainly of (1) ISCRM a file-transfer subprogram that makes it possible for legacy codes executed in their original operating systems on their original computers to exchange data and (2) CONES an easy-to-use filewrapper subprogram that enables the integration of legacy codes. RECIPE provides a tightly integrated conceptual framework that emphasizes connectivity among the programs used by the collaborators, linking these programs in a manner that provides some configuration control while facilitating collaborative engineering tradeoff studies, including design to cost studies. In comparison with prior collaborative-engineering schemes, one based on the use of RECIPE enables fewer engineers to do more in less time.
Stanley, Thomas Troy↗
NLS Advanced Development - Launch operations
Attention is given to Autonomous Launch Operations (ALO), one of a number of the USAF's National Launch System (NLS) Launch Operations projects whose aim is to research, develop and apply new technologies and more efficient approaches toward launch operations. The goal of the ALO project is to develop generic control and monitor software for launch operation subsystems. The result is enhanced reliability of system design, and reduced software development and retention of expert knowledge throughout the life-cycle of the system.
Parrish, Carrie L.↗
NASA Ares I Crew Launch Vehicle Upper Stage Avionics and Software Overview
Building on the heritage of the Saturn and Space Shuttle Programs for the Design, Development, Test, and Evaluation (DDT and E) of avionics and software for NASA's Ares I Crew Launch Vehicle (CLV), the Ares I Upper Stage Element is a vital part of the Constellation Program's transportation system. The Upper Stage Element's Avionics Subsystem is actively proceeding toward its objective of delivering a flight-certified Upper Stage Avionics System for the Ares I CLV.
Nola, Charles L.↗
Hardware and Software Engineering
The Launch Control System (LCS) is a part of the system used to launch the Space Launch System (SLS). It monitors and control of both vehicle and ground systems for SLS. My internship this spring was focused both on the hardware and software aspects of the command and control system. During my internship I worked in two groups, the Record and Playback Subsystem (RPS) and Kennedy Ground Control Subsystems (KGCS). During my time on RPS, I worked on automating the updating of displays and engineering reports. While on KGCS I worked on creating a power distribution diagram of the Control System Development Lab (CDL) and a new trainer for new interns or employees to gain an understanding of Programmable Logic Controllers (PLCs).
Hardware↗
Ares I Crew Launch Vehicle Upper Stage Avionics and Software Overview
This viewgraph presentation gives an overall description of the avionics and software functions of the Ares I Upper Stage Crew Launch Vehicle. The contents include: 1) IUA Team - Development Approach Roadmap; 2) Ares I US Avionics and Software Development Approach; 3) NDT Responsibilities; 4) Ares I Upper Stage Avionics Locations; 5) Ares I Overall Avionics & Software Functions; 6) Block Diagram Version of Avionics Architecture; 7) Instrument Unit Avionics Preliminary Design; and 8) Upper Stage Avionics External Interfaces.
Nola, Charles L.↗