Appendix C 66 C.10 SEA LAUNCH/ICO F1.
C.10.1 On March 12, 2000, a Sea Launch Zenit lifted off from the Odyssey launch platform positioned on the Equator in the Pacific Ocean. The vehicle was carrying the ICO Global Communications F-1 satellite. Shortly before the launch, however, the ground software failed to close a valve in the pneumatic system of the second stage of the rocket. This system performed several actions, including operation and movement for the steering engine of this stage. Loss of more than 60 percent of the pneumatic system’s pressure reduced the capability of the engine; therefore, the rocket did not gain the altitude and speed necessary to achieve orbit. About eight minutes into the flight, as the Zenit’s second stage was nearing the completion of its firing, the launch was aborted under command of the on-board automatic flight termination system. The rocket issued the command once it sensed a deviation in attitude. Both the rocket and its satellite cargo crashed into the Pacific Ocean about 2,700 miles southeast of the launch site.
C.10.2 The software error was traced back to a change of a variable name in the ground operations software. This name change resulted in a change to the software logic such that the valve failed to close before launch. Ultimately, Sea Launch discovered flaws in their configuration management and software engineering processes, including identifying changes in the system and verifying proper operation after those changes.
C.10.3 Lesson Learned.
Flawed configuration management and software engineering processes can lead to failure (AW&ST 2000, Ray 2000).
C.10.4 References.
“Sea Launch Poised to Fly with PAS-9,” Aviation Week & Space Technology, dated July 3, 2000.
Ray, Justin, “Sea Launch Malfunction Blamed on Software Glitch.” Spaceflight Now, dated March 30, 2000.
http://spaceflightnow.com/sealaunch/ico1/000330software.html.
C.11 COSMOS/QUICKBIRD 1.
C.11.1 On November 28, 2000, the QuickBird 1 satellite was launched aboard a Russian Cosmos-3M rocket from the Plesetsk Cosmodrome. However, ground stations did not detect signals from the satellite after launch. Investigators suggested that a computer error inside the satellite might have caused the U.S.-built spacecraft to deploy its electricity-generating solar arrays while the rocket was still climbing through the atmosphere. The computer error may have resulted from a hold in the launch, which was delayed one hour because a Norwegian tracking station was not ready to monitor the satellite.
C.11.2 Russian officials proposed that an operator forgot to reset the satellite computer to account for the new launch time. As a result, the flight command sequence of the
Appendix C 67 spacecraft began at the original launch time and, following its preprogrammed time line, tried to deploy the solar panels while the satellite was still attached to the rocket during the early phase of the flight.
C.11.3 Lesson Learned.
Failure to understand software risks can lead to mission failure (Clark 2000).
C.11.4 References.
Clark, Stephen, “Commercial Eye-In-The-Sky Appears Lost in Launch Failure.”
Spaceflight Now, 21 November 21, 2002.
http://spaceflightnow.com/news/n0011/20quickbird/.
C.12 MARS ROVER SPIRIT.
C.12.1 NASA’s Mars Exploration Rovers, Spirit and Opportunity, landed on Mars on January 4 and 25, 2004. On January 21, 2004, Spirit abruptly ceased communications with mission control. When contact was re-established, mission control found that Spirit could not complete any task that requested memory from the flight computer.
Examination of the problem showed that the file system was consuming too much memory, causing the computer to reset repeatedly. The root cause of the failure was traced to incorrect configuration parameters in two operating system software modules that controlled the storage of files in memory. Effects of overburdened memory were not recognized or tested during ground tests.
C.12.2 Mission operations personnel recovered Spirit by manually reallocating system memory, deleting unnecessary files and directories, and commanding the computer to create a new file system. Although the rover was recovered, the malfunction took 14 days to diagnose and fix, thereby reducing the nominal mission duration.
C.12.3 A post-anomaly review showed that memory management risks were not understood. In addition, schedule pressures prevented extensive testing and understanding of software functions.
C.12.4 Lesson Learned.
Memory management strategies are important for software assurance (Reeves and Neilson 2005).
C.12.5 References.
Reeves, Glenn and Tracy Neilson, “The Mars Rover Spirit FLASH Anomaly.” Paper presented at the IEEE Aerospace Conference, Big Sky, Montana, March, 2005.
Appendix C 68 C.13 CRYOSAT.
C.13.1 On October 8, 2005, a Russian-built Rockot launch vehicle, carrying the CryoSat satellite, blasted off from Russia's northwestern Plesetsk Cosmodrome. Analysis of the telemetry data indicated that the first stage performed nominally. The second stage performed nominally until main engine cut-off was to occur. However, the second stage main engine failed to shut down at the proper time, and continued to operate until depletion of the remaining fuel. As a consequence, the second stage was not separated from the third stage, and the third stage engine was not ignited. This lack of engine capability resulted in unstable flight, causing the vehicle flight angles to exceed allowable limits. The on-board computer automatically ended the mission at 308 seconds into flight. For the second stage shutdown to succeed, pressurization of the low-pressure tank of the third stage had to have been completed before issuance of the shutdown command.
C.13.2 Failure analysis showed that the command to shut down the second stage engine was generated correctly. However, the completion time for the pressurization sequence was erroneously specified; therefore, pressurization completed after the shutdown command was generated. This failure case had not been identified in development and was not tested. No built-in tests existed for the pressurization time.
C.13.3 Lesson Learned.
Adequate consideration should be given to off-nominal inputs and conditions during design and verification (Briggs 2005, Eurocket 2005).
C.13.4 References.
Briggs, Helen, “Cryosat Rocket Fault Laid Bare.” BBC News, dated October 27, 2005. http://news.bbc.co.uk/1/hi/sci/tech/4381840.stm.
EUROCKOT Launch Services GmbH, “CryoSat Failure Analyzed – KOMPSAT-2 Launch in Spring 2006.” Eurocket Press Release. Bermen, Germany, December 21, 2005,
Appendix D 69 APPENDIX D. COMMERCIAL, MILITARY, AND EXPERIMENTAL AIRCRAFT
ACCIDENTS D.1 Commercial And Military Software Failures.
The space vehicle failures described here discuss incidents resulting in mission failures or anomalies without impacts to the uninvolved public. However, such incidents illustrate the importance of software and computing systems in the operation of space and launch vehicles. Unfortunately, software has been a cause of several accidents resulting in injury and loss of life in commercial and military aircraft. Some of those accidents are described below.
D.2 X-31.
D.2.1 An X-31 U.S. government research aircraft was destroyed when it crashed in an unpopulated area just north of Edwards Air Force Base while on a flight originating from the NASA Dryden Flight Research Center, Edwards, California, on January 19, 1995. The crash occurred when the aircraft was returning after completing the third research mission of the day. The pilot safely ejected from the aircraft but suffered serious injuries.
D.2.2 A mishap investigation board studying the cause of the X-31 accident concluded that an accumulation of ice in or on the unheated pitot-static system of the aircraft provided false airspeed information to the flight control computers. The resulting false reading of total air pressure data caused the flight control system of the aircraft to automatically configure for a lower speed. The aircraft suddenly began oscillating in all axes, pitched up to over 90 degrees angle of attack and became uncontrollable, prompting the pilot to eject.
D.2.3 The mishap investigation board also faulted the safety analyses, performed by Rockwell and repeated by NASA, which underestimated the severity of the effect of large errors in the pitot-static system. Rockwell and NASA had assumed that the flight software would use the backup flight control mode if this problem occurred.
D.2.4 Lesson Learned.
Estimating and mitigating software risks, including software used to mitigate hardware anomalies, are critical aspects of software safety (Dornheim 1995, Haley 1995).
D.2.5 References.
Dornheim, Michael A. “X-31 Board Cites Safety Analyses, But Not All Agree.”
Aviation Week & Space Technology, pp. 81-86, dated December 4, 1995.
Haley, Don. “Ice Cause of X-31 Crash.” NASA Dryden Flight Research Center, Edwards, California. NASA Press Release 95-203, 1995.
Appendix D 70 D.3 F-22 RAPTOR.
D.3.1 On February 11, 2007, a flight of 12 F-22’s, on their first deployment to Japan from Hawaii, encountered a multiple system failure at the International Date Line. When the fighters crossed the line, they lost all navigation and attitude indication systems, and parts of their communication and fuel systems including their radios. Fortunately, they were re-fueling at the time and were able to follow the tankers back to Hawaii. The errors were fixed in about 48 hours, and the planes completed their deployment following the software fix.
D.3.2 Lesson Learned.
Software should be tested across the entire environment in which it will operate (Defense Industry Daily, 2007).
D.3.3 References.
“F-22 Squadron Shot Down by the International Date Line.” Defense Industry Daily, 2007. http://www.defenseindustrydaily.com/f22-squadron-shot-down-by-theinternational-date-line-03087/.
OMB Control Number: 2120-0746 (Expiration Date: 08/31/2023) FAA Form 1320-73 (06-2020)
Advisory Circular Feedback Form
If you find an error in this AC, have recommendations for improving it, or have suggestions for new items/subjects to be added, you may let us know by (1) emailing this form to ASTApplications@faa.gov, or (2) faxing it to (202) 267-5450.
Subject: AC 450.141-1A Date: Click here to enter text.
Please check all appropriate line items:
☐ An error (procedural or typographical) has been noted in paragraph Click here to enter text.
on page Click here to enter text..
☐ Recommend paragraph Click here to enter text. on page Click here to enter text. be changed as follows:
Click here to enter text.
☐ In a future change to this AC, please cover the following subject:
(Briefly describe what you want added.)
Click here to enter text.
☐ Other comments:
Click here to enter text.
☐ I would like to discuss the above. Please contact me.
Submitted by: Date:
Paperwork Reduction Act Burden Statement: A federal agency may not conduct or sponsor, and a person is not required to respond to, nor shall a person be subject to a penalty for failure to comply with a collection of information subject to the requirements of the Paperwork Reduction Act unless that collection of information displays a currently valid OMB Control Number. The OMB Control Number for this information collection is 2120-0746. Public reporting for this collection of information is estimated to be approximately 5 minutes per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. All responses to this collection of information are voluntary to obtain or retain benefits per 14 CFR 77. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to: Information Collection Clearance Officer, Federal Aviation Administration, 10101 Hillwood Parkway, Fort Worth, TX 76177-1524.