Appendix A 45 Configuration Management.
A.10.1 Software safety-critical functions and associated interfaces should be put under formal configuration control as soon as a software baseline is established.
A.10.2 A software configuration control board should be created to set up configuration control processes and pre-approve changes to configuration-controlled software.
A.10.3 The software configuration control board should include a member from the system safety engineering team, tasked with the responsibility of evaluating all proposed software changes for potential safety impacts.
A.10.4 Object code patches should not be performed without specific approval.
A.10.5 All software safety-critical functions should be identified as “safety-critical.”
A.10.6 The software configuration management process should include version identification, access control, and change audits. In addition, the ability to restore previous revisions of the system should be maintained throughout the entire life cycle of the software.
A.10.7 All software changes should be evaluated for potential safety impact, and the FAA should be advised of proposed changes that impact safety.
A.10.8 All software changes should be coded with a unique version identification number in the source code, then compiled and tested before introduction into operational equipment.
A.10.9 All software safety-critical functions and associated interfaces should be under configuration control.
A.10.10 Appropriate safeguards should be implemented to prevent non-operational hardware and software from being inadvertently identified as operational.
A.10.11 Test and simulation software should be positively identified as non-operational.
A.10.12 The run-time build should only include software that is built from contractordeveloped software source modules, or COTS software object modules that are traceable to a requirement or derived requirement identified in the requirements or design documentation.
Appendix A 46 Quality Assurance.
A.11.1 A quality assurance function should be implemented to verify that objectives are being satisfied and deficiencies are detected, evaluated, tracked, and resolved.
This quality assurance function includes audits; code walk-throughs; and inspections of elements and processes, such as plans, standards, problemtracking systems, configuration management systems, and system life cycles.
A.12 Security.
A.12.1 The software should be designed to prevent unauthorized system or subsystem interaction from initiating or sustaining a software safety-critical function sequence.
A.12.2 The system design should prevent unauthorized or inadvertent access to or modification of the software (source or assembly) and object code. This security measure includes preventing self-modification of the code.
Software Design, Development, and Test Standards.
Software should be designed, developed, and tested in a manner that complies with IEEE/ISO/IEC 12207, International Standards Systems and software engineering – Software life cycle processes, or its equivalent.
Software Coding Practices.
Software developers should apply software engineering criteria to select a programming language, or languages, for the safety software. This includes utilizing the information provided in ISO/IEC TR 24772, Programming languages — Guidance to avoiding vulnerabilities in programming languages.
Project coding guidelines should be defined for each programming language used in the safety software implementation and should include mitigation for the vulnerabilities described in the relevant parts of ISO/IEC TR 24772.
Appendix A 47 Software Reuse.
Reused software encompasses software developed for other projects by the developer as well as any open source or public domain software selected for the project. Such software should be evaluated to determine if it is a software safety-critical function. Reused safety-critical software should comply with all safety-critical provisions required of newly developed software. For example, an operator should analyze reused software that performs a safety-critical function for the following items:
Correctness of new or existing system design assumptions and requirements.
Impacts on the overall system as the reused software runs on or interfaces with replaced equipment, new hardware, or both.
Changes in the environmental or operating conditions.
Impacts to existing hazards.
Correctness of the interfaces between system hardware; other software; and crew, ground operators, or controlling executive.
Safety-critical computing system functions compiled with a different compiler.
Commercial off-the-shelf (COTS) Software.
A.16.1 When employing COTS software, an operator should ensure that every software safety-critical function that the software supports is identified and satisfies the safety requirements.
A.16.2 Software hazard analyses should be performed on all COTS software used for software safety-critical functions.
A.16.3 Software safety-critical functions identified in COTS software should comply with all safety requirements or be validated for intended use and environment.
Compliance, validation method, and evidence are subject to FAA approval and should be documented.
Appendix B
48 APPENDIX B. SOFTWARE AND COMPUTING SYSTEM HAZARD ANALYSES.
This appendix describes two methods for conducting software and computing system hazard analyses: Software Failure Modes and Effects Analysis (SFMEA) and Software Fault Tree Analyses (SFTA). Examples of the use of SFMEA and SFTA are provided. Other approaches may be acceptable to the FAA. Note that the analysis method used and the level of detail in that analysis will be made based on the complexity of the system, difficulty of the operations, and scope of the program.
B.1 Software Failure Modes and Effects Analysis.
As described in the FAA/AST Guide to Reusable Launch and Reentry Vehicle Reliability Analyses, a Failure Modes and Effects Analysis (FMEA) is a bottomup, inductive reliability and safety analysis method used to identify potential failure modes, effects on the system, risk reduction measures, and safety requirements. Although the steps to performing a SFMEA are similar to those of a hardware FMEA, an SFMEA differs in the following ways:
Hardware failure modes generally include aging, wear-out, and stress, while software failure modes are functional failures resulting from software faults.
Hardware FMEA analyzes both severity and likelihood of the failure, while an SFMEA usually analyzes only the severity of the failure mode.
B.1.1 Typical SFMEA Procedural Steps.
Software Failure Modes and Effects Analysis allows for systematic evaluation of software and computing system failure modes and errors. In addition, this analysis helps to prioritize the verification effort to focus on those functions that have the most influence on the safety of the system. One procedure for performing an SFMEA is as follows:
1. Define the system to be analyzed. The system definition includes identification of modules. In addition, system definitions can include a description of interfaces between software and other systems, flow charts describing data flow or operations, logic diagrams, and user documentation.
2. Categorize the system into elements to be analyzed.
3. Identify potential software faults and computing system failure modes.
4. Identify the potential causes (specific faults leading to the error or failure).
Identifying the specific causes helps to define mitigation measures and test cases.
5. Identify the local and system effects of each failure mode or software error.
6. Identify controls and requirements to mitigate the risks for each failure mode.
Appendix B 49
7. Document the analysis using an SFMEA worksheet.
B.1.2 In the majority of cases, failure modes for hardware components are understood and can be based on operational experience. A hardware FMEA can be based on the known hardware failures for a particular design or class of piece part, component, or subsystem. These hardware failures often result from such factors as wear-out, unanticipated stress, or operational variation. For software, such operational experience often does not exist. Software does not break or fall out of tolerance in the same way hardware does; therefore, software and computing system failure modes or software errors should be identified using generalized classifications. Error! Reference source not found. shows one example of a c lassification set derived from information in such standards as IEEE STD 1044- 2009, IEEE Standard Classification for Software Anomalies, (Inactive). This table does not list all possible faults and failures; therefore, an operator should consider these and others specific to its system when performing software hazard analyses.
Table B-1 Example Classification of Software and Computing System Errors Software and Computing System Failure Mode (Software Error) Class Specific Software and Computing System Faults and Failures Requirements System responses not defined for all operating conditions.
Constraints not testable or left untested.
Safe states incorrectly defined.
Code documentation compiled inaccurately.
Programming practices not defined.
Test plan incorrect or incomplete.
Review processes incomplete or inaccurate.
Reused software not fully compatible with new application.
Program assumptions not documented.
Calculation Inappropriate equation for a calculation.
Incorrect use of parenthesis.
Inappropriate precision.
Round fault (or truncation fault).
Lack of convergence in calculation.
Operand incorrect in equation.
Operator incorrect in equation.
Sign fault.
Capacity overflow, underflow, or both.
Inappropriate accuracy.
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.