Appendix B
Table B-3 Common Fault Tree Logic and Event Symbols Symbol Description Top Event – Foreseeable, undesirable occurrence (also used for an intermediate event).
“OR” Gate – Any of the events below gate will lead to an event above the OR gate.
“AND” Gate – All events below gate must occur for event above gate to AND occur.
Undeveloped Event – An event not further developed because of a lack of need, resources, or information.
Initiator (Basic Event) – Initiating fault or failure, not developed further (marks limit of analysis).
7. Repeat until the analysis reaches a desired level. The bottom-most contributors are known as initiators or basic events.
8. Evaluate the tree to determine the validity of the input and failure paths.
9. Identify specific safety requirements.
10. Document the SFTA results.
B.2.4 An SFTA allows for systematic evaluation of the risks of complex software and computing systems. Using an SFTA helps to discover common cause failures and single-point failures, critical fault paths, and design weaknesses and to identify the best places to build in fault tolerance. In addition, an SFTA helps to prioritize the verification effort to focus on those functions with a large amount of influence on the safety of the system. Czerny (2005), Dunn (2002), Dehlinger and Lutz (2004), and Gowen (1996) provide examples of SFTA developed for other industries.
B.2.5 In developing an SFTA, a developer normally starts with a general FTA that describes the potential impacts of a safety-critical software function with respect to a large system. Figure B-1 shows an example of a fault tree for engine shutdown failure that 57
Appendix B 58 includes hardware, software, and procedures. The contributing event, “Software or computing system error,” can be expanded further. Figure B-2 shows a portion of a fault tree expanding this undesirable event. Note that the “logic error,” “data error,” and “data input error” basic events could be expanded further if necessary to identify specific areas of concern, such as out of range variables, logic sequences out of order, or other faults identified in Table B-1.
Figure B-1 Fault Tree for Engine Shutdown Failure.
Incorrect procedure Improper training Unable to shutdown engine after cutoff Valve 2 fails to close Automatic controller fails to close valve (valve 1) Failure to close manual valve (valve 2)
Software or computing system error Valve 1 fails to close
Mechanical failure
Mechanical failure Contamination Operator fails to close Contamination
Appendix B 59
Software or computing system error Shutdown module does not issue command to actuator Shutdown module does not receive shutdown command Power lost to CPU
Backup battery loss Main battery loss
Logic error
Data error Computer system crash
Watchdog timer/reboot failure Memory or CPU overflow
Sensor failure
Data input error Figure B-2 Fault Tree for Software or Computing System Errors
Appendix C 60 APPENDIX C. SPACE VEHICLES FAILURES AND AIRCRAFT ACCIDENTS C.1 Space Vehicle Failures.
C.1.1 Software and its associated computing system hardware have played a significant role in the root cause of several high-profile space vehicle failures, as described in various accident investigation reports and studies. Although the following is not a comprehensive list of all failures where software played a role, the descriptions help provide an understanding of the types of failures that can be traced to software and computing systems and provide lessons learned for the design of future systems.
C.2 PHOBOS 1.
C.2.1 The Phobos 1 spacecraft was launched on July 7, 1988, on a mission to conduct surface and atmospheric studies of Mars. The vehicle operated normally until routine attempts to communicate with the spacecraft failed on September 2, 1988, and the mission was lost. Examination of the failure showed that a ground control operator had omitted a single letter in a series of digital commands sent to the spacecraft. The computer mistranslated this command and started a ground checkout test sequence, deactivating the attitude control thrusters. As a result, the spacecraft lost its lock on the Sun. Because the solar panels pointed away from the Sun, the on-board batteries were eventually drained, and all power was lost.
C.2.2 A lack of requirements taking the human and software interface into account contributed to the failure. Additionally, error-checking functions had been turned off during the data transfer operation.
C.2.3 Lesson Learned.
Error checking and isolating test software from flight software are important aspects of software assurance (Norman 1990, Perminov 1999).
C.2.4 References.
Norman, Don A. “Commentary: Human Error and the Design of Computer Systems.” Communications of the ACM, vol. 33, pp. 4-7. 1990.
Perminov, V. G. The Difficult Road to Mars: A Brief History of Mars Exploration in the Soviet Union. NASA Monographs in Aerospace History, no. 15. NP-1999-06- 251-HQ. 1999.
C.3 CLEMENTINE.
C.3.1 The Deep Space Program Science Experiment, also known as the Clementine spacecraft, was launched on January 25, 1994. The spacecraft entered lunar orbit, functioned flawlessly, and departed from the Moon on May 3, 1994, to rendezvous with its target, asteroid 1620 Geographos. However, four days later, a flaw in the software
Appendix C 61 resulted in the computer firing the attitude control thrusters until the supply of propellant had been exhausted. The malfunction left the spacecraft in a stable spin that, when combined with the spacecraft’s heliocentric orbit, would ultimately prevent the generation of adequate power to operate the spacecraft. This condition led to abandonment of the mission.
C.3.2 Although the root cause of the problem could not be definitively determined, some researchers have suggested that a floating-point exception may have caused the computer to crash, allowing the thrusters to operate continuously. Inadequate testing, a tight schedule, and cost pressures also may have increased the chances of failure.
C.3.3 Lesson Learned.
A watchdog timer may have been used to reset the computer automatically and avert failure (Chapman and Regeon 1996, Ganssle 2000, Harland and Lorenz 2005).
C.3.4 References.
Chapman, R. Jack and Paul A. Regeon. “The Clementine Lunar Orbiter Project.”
Unpublished paper presented at the Austrian Space Agency Summer School, Alpbach, Germany, July 26 to August 3, 1995.
Ganssle, Jack G., “Crash and Burn.” Embedded Systems Programming, 2000.
https://www.embedded.com/crash-and-burn/.
Harland, David M. and Ralph D. Lorenz, Space System Failures: Disasters and Rescues of Satellites, Rockets, and Space Probes. Berlin: Praxis Publishing Ltd.
2005.
C.4 ARIANE 501.
C.4.1 On June 4, 1996, the Ariane 5 launch vehicle veered off course and broke up approximately 40 seconds into launch. The vehicle started to disintegrate because of high aerodynamic loads resulting from an angle of attack greater than 20 degrees. This condition led to separation of the boosters from the main stage, in turn triggering the self-destruct system of the launcher. This improper angle of attack was caused by full nozzle deflections of the solid boosters and the Vulcain main engine. The on-board computer software commanded these nozzle deflections based on data received from the active Inertial Reference System. Ultimately, these improper deflections resulted from requirement and design errors in the Inertial Reference System software, including improper error handling. An unexpected horizontal velocity component led to an overflow condition, which was not handled properly by the software.
C.4.2 Reused software from the Ariane 4 program, including the exception handling code used in the Inertial Reference System, contributed to the failure. The source of the fault occurred in a function that was not required for Ariane 5, but rather was a function carried over from the Ariane 4 software. The development team believed that faults would be caused by a random hardware failure, handled by redundancy in the hardware.
However, because the problem was a requirements problem instead of a random
Appendix C 62 hardware failure, both the primary and backup Inertial Reference Systems shutdown nearly simultaneously from the same cause. In addition, no end-to-end tests were conducted to verify that the Inertial Reference System and its software would behave correctly when subjected to the countdown sequence, flight time sequence, and trajectory of Ariane 5.
C.4.3 Lesson Learned.
Multiple factors can contribute to failure, including a misunderstanding of the software risks, especially of reused software; complex software design; insufficient system engineering efforts; flawed requirements and failure to fully analyze those requirements; and insufficient testing (Lions 1996, O’Halloran 2005).
C.4.4 References.
Lions, J. L., Ariane5: Flight 501Failure Report by the Inquiry Board. Paris:
European Space Agency, 1996.
O’Halloran, Colin, et al. “Ariane 5: Learning from Failure.” Proceedings of the 23rd International System Safety Conference, August at San Diego, California, 2005.
C.5 DELTA III/GALAXY.
C.5.1 On August 27, 1998, the first Boeing Delta III ever flown was launched from Pad 17B at Cape Canaveral Air Station, Florida. Its mission was to place the GALAXY X commercial communications spacecraft into a nominal transfer orbit. At 65 seconds after liftoff, the air-lit Solid Rocket Motors (SRMs) ceased to swivel, leaving two motors in positions that helped overturn the vehicle. The vehicle yawed about 35 degrees. Approximately 71 seconds after lift-off, it began to disintegrate at an altitude of about 60,000 feet. A destruct signal was sent 75 seconds into the flight, which completed destruction of the vehicle. Analysis revealed that between 55 and 65 seconds into the flight, roll oscillations around four Hz prompted the control system of the vehicle to gimbal its three swiveling SRMs. The control system software commanded the system to respond to the oscillation, and the SRMs gimbaled with these commands until the hydraulic system ran out of fluid. Once the hydraulic fluid was expended, the oscillations appeared to smooth out. Unfortunately, however, after the hydraulic fluid had been expended, two of the three swiveling SRMs were stuck in the wrong position, and wind shear forced the Delta III to yaw and break up seven seconds later.
C.5.2 The review team concluded that the flight would not have failed if the control system software had not commanded the system to respond to the four Hz roll oscillations because the vehicle oscillations would have smoothed out on their own. As a result of the investigation, Boeing changed an instruction to the flight control system, so the software would identify and ignore the four Hz roll oscillation in subsequent Delta III flights.
Appendix C 63 C.5.3 Lesson Learned.
An inadequate understanding of the interactions between software and hardware could lead to failure (Boeing 1998).
C.5.4 References.
The Boeing Company. “Boeing Pinpoints Cause of Delta 3 Failure, Predicts Timely Return to Flight.” Boeing Press Release, 1998.
C.6 ZENIT/GLOBALSTAR.
C.6.1 On September 9, 1998, a two-stage Ukrainian-built Zenit 2 rocket, carrying 12 Globalstar satellites, was launched from Baikonur, Kazakhstan. According to the National Space Agency of Ukraine, the second stage of the booster rocket shutdown at approximately 276 seconds into flight. The nose cone carrying the 12 satellites automatically disengaged from the booster rocket with the shutdown and fell to Earth in remote southern Siberia. The booster rocket followed. Although the root cause of the failure could not be definitively confirmed, a malfunction of the flight control computers or software, which led to the premature shutdown of the second stage, was the most likely cause. Telemetry data indicated that two of the three primary flight computers shut down, a situation that left the third computer unable to control the vehicle, resulting in the cutoff of the engine.
C.6.2 Lesson Learned.
A lack of understanding of the risks associated with software and computing systems can lead to failure (Wired News 1998, Woronowycz 1998).
C.6.3 References.
Wired News. “12 Satellites Go Down in Russia.” dated September 10, 1998.https://www.wired.com/1998/09/12-satellites-go-down-in-russia/.
Woronowycz, Roman. “Crash of Ukrainian Rocket Imperils Space Program.” The Ukrainian Weekly, vol. 66, no. 38, dated September 20, 1998.
C.7 MARS CLIMATE ORBITER.
C.7.1 The Mars Climate Orbiter (MCO) was launched on December 11, 1998, and was lost on September 23, 1999, as it entered the Martian atmosphere in a lower than expected trajectory. The investigation board identified the failure to use metric units in the coding of a ground software file used in the trajectory models as the root cause. These trajectory models produced data ultimately used to define the vehicle’s trajectory for the flight computer. Thruster performance data were in English units instead of metric. As a result, an erroneous trajectory was calculated which led to the vehicle crashing onto the surface rather than entering into an orbit around Mars. Formal acceptance testing failed to capture the problem because the test article used for comparison contained the same error as the output file from the actual unit.
Appendix C 64 C.7.2 Incomplete requirements were a contributing factor. The requirements did not dictate the units to be used. Also, a lack of warning marks in the original code, identifying the potential problem, contributed to the failure. The MCO investigators also cited inadequacies in risk identification, communication, management, and mitigation that compromised mission success. In part, these inadequacies resulted from cost and schedule pressures.
C.7.3 Lesson Learned.
Multiple factors can lead to failure, including inadequate testing, incomplete requirements, and inadequate risk management (Leveson 2004, Stephenson 1999).
C.7.4 References.
Leveson, Nancy G. “The Role of Software in Spacecraft Accidents.” AIAA Journal of Spacecraft and Rockets, vol. 41, no. 4, pp. 564-575, 2004.
C.8 MARS POLAR LANDER.
C.8.1 The Mars Polar Lander (MPL) was launched on January 3, 1999. Upon arrival at Mars, communications ended according to plan as the vehicle prepared to enter the Martian atmosphere. Communications were scheduled to resume after the Lander and the probes were on the surface. However, repeated efforts to contact the vehicle failed. The cause of the MPL loss was never fully identified, but the most likely scenario was that the problem involved deployment of the three landing legs during the landing sequence.
Each leg was fitted with a Hall Effect magnetic sensor that generated a voltage when the leg contacted the surface of Mars. A command from the flight software was to shut down the descent engines when touchdown was detected. The MPL investigators believed that the software interpreted spurious signals generated at leg deployment as valid touchdown events, leading to premature shutdown of the engines at 40 meters above the surface of Mars, resulting in the vehicle crashing into the surface.
C.8.2 Although a possible failure mode whereby the sensors would falsely detect that the vehicle had touched down was known to exist, the software requirements did not account for this failure mode. Therefore, the software was not programmed to avoid such an occurrence. Although the validation and verification program was well planned and executed, the MPL failure report noted, analysis was often substituted for testing to save costs. Such analysis may have lacked adequate fidelity. Also, the touchdown sensing software was not tested with the Lander in the flight configuration. The MPL investigators specifically recommended that system software testing include stress testing and fault injection in a suitable simulation environment to determine the limits of capability and search for hidden flaws.
C.8.3 Lesson Learned.
Multiple factors can lead to failure, including insufficient system engineering efforts, insufficient testing, flawed review processes, and flawed requirements (JPL 2000, Leveson 2004).
Appendix C 65 C.8.4 References.
NASA, Jet Propulsion Laboratory. Report on the Loss of the Mars Polar Lander and Deep Space 2 Missions. JPL D-18709, 2000.
Leveson, Nancy G. “The Role of Software in Spacecraft Accidents.” AIAA Journal of Spacecraft and Rockets, vol. 41, no. 4, pp. 564-575, 2004.
C.9 TITAN/CENTAUR-MILSTAR.
C.9.1 On April 30, 1999, a Titan IV B vehicle (Titan IV B-32), with a Titan Centaur upper stage (TC-14) was launched from Space Launch Complex 40 at Cape Canaveral Air Station, Florida. The mission was to place a Milstar satellite into geosynchronous orbit.
The flight performance of the Titan solid rocket motors and core vehicle was nominal, and the Centaur upper stage separated properly from the Titan IV B. The vehicle began experiencing instability about the roll axis during the first Centaur burn. That instability was greatly magnified during Centaur’s second main engine burn, resulting in uncontrolled vehicle tumbling. The Centaur tried to compensate for those attitude errors by using its Reaction Control System. Such attempts ultimately depleted available propellant during the transfer orbit coast phase. The third engine burn ended early because of the tumbling vehicle motion. As a result of the anomalous events, the Milstar satellite was placed in a low elliptical final orbit instead of the intended geosynchronous orbit.
C.9.2 The Accident Investigation Board concluded that a failed software development, testing, and quality assurance process for the Centaur upper stage caused the failure of the Titan IV B-32 mission. That failed engineering process did not detect nor did it correct a human error in the manual entry of the roll rate filter constant entered in the Inertial Measurement System flight software file. Evidence of the incorrect constant appeared during launch processing and the launch countdown, but its impact was insufficiently recognized or understood. Consequently, this error was not corrected before launch. The incorrect roll rate filter constant zeroed any roll rate data, resulting in the loss of control. The Board noted that the manually input values were never formally tested in any of the simulations before launch, and simulator testing was not performed as the system was supposed to be flown.
C.9.3 Lesson Learned.
Flawed engineering processes, underestimation of the software risks, and inadequate software reviews can lead to failure (Leveson 2004, Pavlovich 1999).
C.9.4 References.
Pavlovich, J. Gregory. Formal Report of Investigation of the 30 April 1999 Titan IVB/Centaur TC-14/Milstar-3 (B-32) Space Launch Mishap. Washington, D.C.:
U.S. Air Force, 1999.
Leveson, Nancy G., “The Role of Software in Spacecraft Accidents.” AIAA Journal of Spacecraft and Rockets, vol. 41, no. 4, pp. 564-575, 2004.
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,