Appendix B 50 Software and Computing System Failure Mode (Software Error) Class Specific Software and Computing System Faults and Failures Use of incorrect instruction.
Data Undefined data.
Non-initialized data.
Data defined several times.
Incorrect adapt protection.
Variable type incorrect.
Range incorrect.
Wrong use of data (bit alignment, global data).
Fault in the use of complex data (record, array, pointer).
No use of data.
Data stuck at some value.
Interface Data corruption.
Bad parameters in call between two procedures.
No or null parameters in the call between two procedures.
Non-existent call between two procedures.
Wrong call between two procedures.
Inappropriate end-to-end numerical resolution.
Wrong message communication (bad error handling).
Empty or no message communication (bad or no error handling).
Incorrect creation, deletion, or suspension of a task.
Software responds incorrectly to no data.
Wrong synchronization between tasks (task not invoked because of its low priority).
Incorrect task blocking.
Wrong commands or messages given by the user, operator, or both.
No commands given by the user, operator, or both.
Commands not given in time by the user, operator, or both.
Commands given at wrong time by the user, operator, or both.
Logic Wrong order of sequences (modules called at wrong time).
Wrong use of arithmetic or logical instruction.
Wrong or missing test condition.
Wrong use of branch instruction.
Timing overrun.
Appendix B 51 Software and Computing System Failure Mode (Software Error) Class Specific Software and Computing System Faults and Failures Missing sequence.
Wrong use of a macro.
Wrong or missing iterative sequence.
Wrong algorithm.
Shared data overwritten.
Unnecessary function.
Unreachable code.
Dead code.
Environment Compiler error.
Wrong use of tools options (optimize, debug).
Bad association of files during code link.
Change in operating system leads to software bug.
Change in third-party software leads to software bug.
Hardware CPU overload.
Memory overload.
Unexpected shutdown of the computer.
Wrong file writing.
Wrong interrupt activation.
Wrong data into register or memory.
Processor computation incorrect.
No file writing.
No interrupt activation.
No data into register or memory.
Loss of operator visualization (loss of screen display).
Untimely file writing.
Untimely data into memory or register.
Untimely interrupt activation.
Untimely operator visualization.
Appendix B 52 B.1.3 Error! Reference source not found. shows an SFMEA worksheet for functions a nd computing system hardware components in a hypothetical RLV. While the analyses in these examples are focused on software functions, an SFMEA can be performed at any level, for example, a software package or module. Analyses at lower levels, such as at the code, provide the most information but also require the most resources. The scope of the analysis will depend on the particular software and development program. Examples of SFMEA developed for other industries are provided in Czerny (2005), Dunn (2002), Feng and Lutz (2005), Ozarin (2006), and Wood (1999).
B.1.4 Performing an SFMEA as early as possible in the development process is desirable. Note, however, the software design is highly subject to change because designers continually make beneficial modifications during development. Therefore, updating the SFMEA throughout the development process to reflect these changes is important.
Appendix B 53 Table B-2 Example Software and Computing System Failure Modes and Effects Analysis Worksheet 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 PS-1 Function:
PROP_SENS Acquire temperature and pressure sensor inputs from propulsion system, and provide information to flight control modules and automated shutdown routines.
Function fails to work or performs incompletely because of logic, data, or interface errors.
Wrong use of branch instruction.
Data out of range.
Missing data.
Non-existent or incorrect call between procedures.
Missing errorhandling routine.
Function called at wrong time.
No sensor readings obtained from the propulsion system.
Continuing to operate with last sensor inputs.
Failing to detect out-of-range condition.
Failing to issue proper abort and propulsion shutdown commands.
Using a separate software execution monitoring function to detect whether the function was completed.
Verifying sensors before flight.
PS-2 Function:
PROP_SENS Acquire temperature and pressure sensor input from propulsion system and provide information to flight control modules and automated shutdown routines.
Function works incorrectly because of calculation, logic, data, or interface errors.
Incorrect conversion calculation.
Wrong use of branch instruction.
Wrong use of data.
Data out of range.
Missing data.
Missing errorhandling routine.
Function called at wrong time.
Incorrect sensor signals received from the propulsion system.
Using incorrect input; therefore, providing incorrect output.
Failing to issue proper abort and propulsion shutdown commands.
Using a separate software function to detect out of range conditions for temperature and pressure.
Providing independent temperature and pressure readings to pilots to use for manual shutdown purposes.
Verifying sensors before flight.
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