The following HTML text is provided to enhance online
readability. Many aspects of typography translate only awkwardly to HTML.
Please use the page image
as the authoritative form to ensure accuracy.
An Assessment of Space Shuttle Flight Software Development Processes
The Backup Flight Software (BFS) provides backup capability for the critical phases of a mission and therefore contains only the software necessary to complete ascent or entry safely, maintain vehicle control on orbit, and perform the systems management function during ascent and entry (when there is no PASS systems management). Because its functions are limited, all the BFS software can fit into a computer at the same time and need never access mass memory (although a copy of the BFS software is loaded into the mass memory unit so that another computer could take over the functions of the backup computer in case of a backup computer failure). The BFS is designed to monitor everything that PASS does during ascent and entry.
The application flight software (and occasionally system software) has to be changed as a result of changes in Shuttle hardware (including an upgrade in the computers used), detected errors, and decisions to add functionality. As stated earlier, these major updates to the software are called Operational Increments (OIs) and occur approximately once a year. As can be seen in Figure 3-1, each operational increment takes up to 28 months to develop, so the development of different operational increments proceeds in parallel.
In addition to the basic software, each mission has specific requirements that relate to the activities to be carried out on that flight. The software development contractors deliver the OI base to the Space Transportation System Operations Contractor (STSOC), who configures it for the mission by adding mission-specific (payload) data, initialization data, telemetry format data, and flight software patches (corrections in response to late change requests and discrepancy reports) to produce a final integrated mass memory load.
The process for Shuttle software development and V&V is more complex than is practical to present completely here. In addition, a number of the internal processes used by the development contractors are deemed proprietary. Although the Committee was given access to much of this proprietary information, it is not appropriate for publication in this report. Instead, the Committee has included documents in Appendix D and Appendix E that provide detailed but non-proprietary information. The Committee feels it is helpful in understanding the findings and recommendations, however, to have an overall view of the process.
Figure 3-2a, Figure 3-2b through Figure 3-2c (Figure 5-1, Figure 5-2 through Figure 5-3 of the roadmap document included in Appendix E) show the development-process steps, and the V&V activities associated with each step, for the PASS and BFS software developed at JSC. Figure 3-3a, Figure 3-3b, Figure 3-3c, through Figure 3-3d are similar descriptions of the process steps and V&V activities for the Block 1 Space Shuttle Main Engine Controller (SSMEC) developed by the Marshall Space Flight Center (MSFC). The Block 1 SSMEC roadmap differs from the roadmap used at JSC for the PASS and BFS. In addition, there has recently been a major upgrade to the SSMEC (again developed by Rocketdyne for MSFC), called Block 2, which uses a third roadmap that is similar, but not identical, to the Block 1 roadmap. Also, each of the software development contractors (IBM, Rockwell/Downey, and Rocketdyne) have their own internal software development and V&V processes that are not shown on any of the roadmaps.