Appendix B 54 Table B-2. Example Software and Computing System Failure Modes and Effects Analysis worksheet (cont’d) Item No.
Software or Computing System Element Failure Mode or Software Error Error Cause (Specific Fault Type) Local Effect System Effect or Hazard Risk Mitigation Measures CV-1 Function:
CLOSE_VALVE When limits are exceeded command the main fuel and oxidizer valves to close.
Function fails to work or performs incompletely because of logic, data, or interface errors.
Wrong use of branch instruction.
Data out of range or incorrect.
Non-existent or incorrect call between procedures.
Missing errorhandling routine.
Signal is not sent to the valve actuators.
Failing to close valves, resulting in continued thrust, flight outside of operating area, or possible loss of vehicle.
Using a separate software execution monitoring function to detect whether the function was completed.
Making manual shutdown procedures available.
GPS-1 Function:
GPS_RECEIVE Acquire GPS signal.
Send vehicle position to other functions.
Abort if location data out of range.
Function fails to execute or executes incompletely because of logic, data, or interface errors.
Wrong use of branch instruction.
Data out of range or incorrect (loss of GPS signal).
Non-existent or incorrect call between procedures.
Missing errorhandling routine.
Position information is not provided.
Using incorrect input or having no GPS location data; therefore, providing incorrect output.
Failing to issue proper abort and propulsion shutdown commands.
Using a separate software function to detect out of range conditions, including location values and signal strength.
Having the main computer initiate an abort if conditions are out of range.
Performing GPS checks before flight.
Appendix B 55 Table B-2. Example Software and Computing System Failure Modes and Effects Analysis worksheet (cont’d) Item No.
Software or Computing System Element Failure Mode or Software Error Error Cause (Specific Fault Type) Local Effect System Effect or Hazard Risk Mitigation Measures CS-1 Main CPU Loss of main computer.
Overload of CPU Loss of power from on-board batteries.
Inadvertent shutdown.
Loss of all safety-critical computer and software functions.
Continuing to operate with last sensor inputs.
Failing to detect out-of-range condition, causing failure to issue proper abort and propulsion shutdown commands.
Using a watchdog timer to detect computing system functionality and trigger a reboot of the main CPU.
Implementing CPU selftests and hardware diagnostics to detect failure.
Initiating abort sequences using a separate on-board CPU.
Making manual shutdown procedures available.
WD-1 Watchdog timer Watchdog timer failure.
Loss of power.
Mechanical or electrical failure.
No system available to monitor CPU loss.
Failing to detect loss of CPU.
Failing to issue proper abort commands if main CPU lost.
Running watchdog computer and main CPU off separate power sources.
Verifying watchdog timer before flight.
Making manual abort procedures available.
Appendix B 56 B.2 Software Fault Tree Analysis.
B.2.1 A top-down, deductive study of system reliability, Fault Tree Analysis (FTA) graphically depicts the sequence of events that can lead to an undesirable outcome. An FTA generates a fault tree, which is a symbolic logic model of the failures and faults.
As an aid for system safety improvement, an FTA is often used to model complex processes. For example, an FTA may be used to estimate the probability that a top-level or causal event will occur, identify systematically possible causes leading to that event, and document the results of the analytic process to provide a baseline for future studies of alternate designs.
B.2.2 A Software Fault Tree Analysis (SFTA) is an extension of the system FTA in which software and computing system contributors to an undesirable event are identified and analyzed. While a hardware FTA can be quantitative or qualitative, an SFTA is not quantitative because of software’s non-probabilistic nature. An SFTA produces safety requirements that can then be implemented in the software life cycle.
B.2.3 Standard logic symbols are used in constructing an SFTA to describe events and logical connections. Error! Reference source not found. shows the most common symbols. T he FAA/AST Guide to Reusable Launch and Reentry Vehicle Reliability Analyses provides additional symbols and information on SFTA. The process for performing an SFTA is as follows:
1. Identify the undesirable events that require analysis. Usually, these occurrences are called pivotal events – events that could ultimately lead to failure of the vehicle or system. Each pivotal event is a top event for the fault tree, and a new tree is required for each top event. The top event is often determined from other analyses, such as a hazard analysis, FMEA, or known undesirable event, such as a mishap.
2. Define the scope of the analysis to determine the level of depth of the analysis needed for each undesirable event. The level of depth may be determined based on the application of the analysis. In some cases, for example, analyzing broad functions may suffice. Other cases may require analyzing errors in specific modules.
3. Identify causes leading to the undesirable event, known as first-level contributors to the top event. Contributors should be independent of each other. For example, for a top event of “Incorrect navigation data on flight control display,” the events “data not calculated correctly” and “inappropriate equation used for calculations” are not independent events. Use of an inappropriate equation may have led to calculating the data incorrectly. To determine events and contributors, data gathering may be required. Sources of this information include requirements, drawings, and block diagrams.
4. Link the first-level contributors to the top event by a logic gate.
5. Identify the second-level contributors to the first-level events.
6. Link the second-level contributors to the first-level contributors.
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.