Shuttle avionics software trials, tribulations and success

The early problems and the solutions developed to provide the required quality software needed to support the space shuttle engine development program are described. The decision to use a programmable digital control system on the space shuttle engine was primarily based upon the need for a flexible control system capable of supporting the total engine mission on a large complex pump fed engine. The mission definition included all control phases from ground checkout through post shutdown propellant dumping. The flexibility of the controller through reprogrammable software allowed the system to respond to the technical challenges and innovation required to develop both the engine and controller hardware. This same flexibility, however, placed a severe strain on the capability of the software development and verification organization. The overall development program required that the software facility accommodate significant growth in both the software requirements and the number of software packages delivered. This challenge was met by reorganization and evolution in the process of developing and verifying software

Production of Reliable Flight Crucial Software: Validation Methods Research for Fault Tolerant Avionics and Control Systems Sub-Working Group Meeting

The state of the art in the production of crucial software for flight control applications was addressed. The association between reliability metrics and software is considered. Thirteen software development projects are discussed. A short term need for research in the areas of tool development and software fault tolerance was indicated. For the long term, research in format verification or proof methods was recommended. Formal specification and software reliability modeling, were recommended as topics for both short and long term research

Construction and Verification of Performance and Reliability Models

Over the last two decades formal methods have been extended towards performance and reliability evaluation. This paper tries to provide a rather intuitive explanation of the basic concepts and features in this area. Instead of striving for mathematical rigour, the intention is to give an illustrative introduction to the basics of stochastic models, to stochastic modelling using process algebra, and to model checking as a technique to analyse stochastic models

Spacelab software development and integration concepts study report, volume 1

The proposed software guidelines to be followed by the European Space Research Organization in the development of software for the Spacelab being developed for use as a payload for the space shuttle are documented. Concepts, techniques, and tools needed to assure the success of a programming project are defined as they relate to operation of the data management subsystem, support of experiments and space applications, use with ground support equipment, and for integration testing

The natural history of bugs: using formal methods to analyse software related failures in space missions

Space missions force engineers to make complex trade-offs between many different constraints including cost, mass, power, functionality and reliability. These constraints create a continual need to innovate. Many advances rely upon software, for instance to control and monitor the next generation ‘electron cyclotron resonance’ ion-drives for deep space missions.Programmers face numerous challenges. It is extremely difficult to conduct valid ground-based tests for the code used in space missions. Abstract models and simulations of satellites can be misleading. These issues are compounded by the use of ‘band-aid’ software to fix design mistakes and compromises in other aspects of space systems engineering. Programmers must often re-code missions in flight. This introduces considerable risks. It should, therefore, not be a surprise that so many space missions fail to achieve their objectives. The costs of failure are considerable. Small launch vehicles, such as the U.S. Pegasus system, cost around $18 million. Payloads range from$4 million up to $1 billion for security related satellites. These costs do not include consequent business losses. In 2005, Intelsat wrote off$73 million from the failure of a single uninsured satellite. It is clearly important that we learn as much as possible from those failures that do occur. The following pages examine the roles that formal methods might play in the analysis of software failures in space missions

Space Station Engineering Design Issues

Space Station Freedom topics addressed include: general design issues; issues related to utilization and operations; issues related to systems requirements and design; and management issues relevant to design

National Security Space Launch

The United States Space Force’s National Security Space Launch (NSSL) program, formerly known as the Evolved Expendable Launch Vehicle (EELV) program, was first established in 1994 by President William J. Clinton’s National Space Transportation Policy. The policy assigned the responsibility for expendable launch vehicles to the Department of Defense (DoD), with the goals of lowering launch costs and ensuring national security access to space. As such, the United States Air Force Space and Missile Systems Center (SMC) started the EELV program to acquire more affordable and reliable launch capability for valuable U.S. military satellites, such as national reconnaissance satellites that cost billions per satellite. In March 2019, the program name was changed from EELV to NSSL, which reflected several important features: 1.) The emphasis on “assured access to space,” 2.) transition from the Russian-made RD-180 rocket engine used on the Atlas V to a US-sourced engine (now scheduled to be complete by 2022), 3.) adaptation to manifest changes (such as enabling satellite swaps and return of manifest to normal operations both within 12 months of a need or an anomaly), and 4.) potential use of reusable launch vehicles. As of August 2019, Blue Origin, Northrop Grumman Innovation Systems, SpaceX, and United Launch Alliance (ULA) have all submitted proposals. From these, the U.S. Air Force will be selecting two companies to fulfill approximately 34 launches over a period of five years, beginning in 2022. This paper will therefore first examine the objectives for the NSSL as presented in the 2017 National Security Strategy, Fiscal Year 2019, Fiscal Year 2020, and Fiscal Year 2021 National Defense Authorization Acts (NDAA), and National Presidential Directive No. 40. The paper will then identify areas of potential weakness and gaps that exist in space launch programs as a whole and explore the security implications that impact the NSSL specifically. Finally, the paper will examine how the trajectory of the NSSL program could be adjusted in order to facilitate a smooth transition into new launch vehicles, while maintaining mission success, minimizing national security vulnerabilities, and clarifying the defense acquisition process.No embargoAcademic Major: EnglishAcademic Major: International Studie

Assessment of the NASA Flight Assurance Review Program

The NASA flight assurance review program to develop minimum standard guidelines for flight assurance reviews was assessed. Documents from NASA centers and NASA headquarters to determine current design review practices and procedures were evaluated. Six reviews were identified for the recommended minimum. The practices and procedures used at the different centers to incorporate the most effective ones into the minimum standard review guidelines were analyzed and guidelines for procedures, personnel and responsibilies, review items/data checklist, and feedback and closeout were defined. The six recommended reviews and the minimum standards guidelines developed for flight assurance reviews are presented. Observations and conclusions for further improving the NASA review and quality assurance process are outlined

Design of the software development and verification system (SWDVS) for shuttle NASA study task 35

An overview of the Software Development and Verification System (SWDVS) for the space shuttle is presented. The design considerations, goals, assumptions, and major features of the design are examined. A scenario that shows three persons involved in flight software development using the SWDVS in response to a program change request is developed. The SWDVS is described from the standpoint of different groups of people with different responsibilities in the shuttle program to show the functional requirements that influenced the SWDVS design. The software elements of the SWDVS that satisfy the requirements of the different groups are identified

Software system safety

Software itself is not hazardous, but since software and hardware share common interfaces there is an opportunity for software to create hazards. Further, these software systems are complex, and proven methods for the design, analysis, and measurement of software safety are not yet available. Some past software failures, future NASA software trends, software engineering methods, and tools and techniques for various software safety analyses are reviewed. Recommendations to NASA are made based on this review