Appendix A 42 A.6.14 Safety-critical operator displays and interface functions should be concise and unambiguous. Where possible, such displays should be duplicated using separate display devices.
Computing System Environment-Software Interface.
A.7.1 The developer should identify the situations in which the application can corrupt the underlying computing environment.
A.7.2 The developer should check for system data integrity at startup.
A.7.3 The system should provide for self-checking of the programs and computing system execution.
A.7.4 Periodic checks of memory, instruction, and data busses should be performed.
A.7.5 Parity checks, checksums, or other techniques should be used to validate data transfer.
Operations.
A.8.1 Operational checks of testable software safety-critical functions should be made immediately before performance of a related safety-critical operation.
A.8.2 Software should provide for flight or ground crew forced execution of any automatic safing, isolation, or switchover functions.
A.8.3 Software should provide for flight or ground crew forced termination of any automatic safing, isolation, or switchover functions.
A.8.4 Software should provide procession for flight or ground crew commands in return to the previous mode or configuration for any automatic safing, isolation, or switchover function.
A.8.5 Software should provide for flight or ground crew forced override of any automatic safing, isolation, or switchover functions.
A.8.6 Hazardous payloads should provide failure status and health data to vehicle software systems, consistent with anomaly detection requirements and anomaly response requirements. Vehicle software systems should process hazardous payload status and data to provide status monitoring and failure annunciation.
A.8.7 The system should have at least one safe state identified for each logistic and operational phase.
A.8.8 Software control of critical functions should have feedback mechanisms that give positive indications of the function’s occurrence.
Appendix A 43 A.8.9 The system and software should ensure that design safety requirements are not violated under peak load conditions.
A.8.10 The system and software should ensure that performance degradation caused by factors, such as memory overload and counter overflow, does not occur over time.
Validation and Verification.
A.9.1 A system safety engineering team should analyze the software throughout the design, development, and maintenance process to validate and verify that the safety design requirements have been implemented correctly and completely.
Test results should be analyzed to identify potential safety anomalies that may occur.
A.9.2 If simulated items, simulators, and test sets are needed, the system should be designed such that the identification of the devices is fail safe. The design should also assure that personnel could not inadvertently identify operational hardware as a simulated item, simulator, or test set.
A.9.3 The vehicle operator should use a problem-tracking system to identify, track, and disposition anomalies during the verification process.
A.9.4 The operator should have the ability to review logged system errors.
A.9.5 For software safety-critical functions, the developer should provide evidence that testing has addressed not only nominal correctness but also robustness in the face of stress. Such testing may involve stimulus and response pairs to demonstrate satisfaction of functional requirements. This approach should include a systematic plan for testing the behavior when capacities and rates are extreme. As a minimum, the plan would identify and demonstrate the behavior of safety-critical software in the face of the failure of various other components.
Examples include having no or fewer input signals from a device for longer periods than operationally expected or, conversely, receiving more frequent input signals from a device than operationally expected.
A.9.6 The developer should provide evidence of the following:
Independence of test planning, execution, and review for safety-critical software; to that end, someone other than the individual developer should develop, review, conduct, and interpret unit tests.
Rate and severity of errors of software safety-critical functions exposed in testing diminishes as the system approaches operational testing.
Tests of software safety-critical functions represent a realistic sampling of expected operational inputs.
Appendix A 44 A.9.7 Software testing should include the following:
Hardware and software input failure modes.
Boundary, out-of-bounds, and boundary crossing conditions.
Minimum and maximum input data rates in worst-case configurations to determine the system’s abilities and responses to these conditions.
Input values of zero, zero crossing, and approaching zero from either direction and similar values for trigonometric functions.
A.9.8 Interface testing should include operator errors during safety-critical operations to verify safe system response to these errors. Issuing the wrong command, failing to issue a command, and issuing commands out of sequence should be among the conditions tested.
A.9.9 Software safety-critical functions in which changes have been made should be subjected to complete regression testing. The regression tests should be maintained and updated as necessary.
A.9.10 Where appropriate, software testing should include duration stress testing. The stress test periods should continue for at least the maximum expected operating time for the system. Operators should conduct testing under simulated operational environments. In addition, software testing should examine the following items:
Inadvertent hardware shutdown and power transients.
Error handling.
Execution path coverage, with all statements completed and every branch tested at least once.
A.9.11 The vehicle operator should evaluate equations and algorithms to ensure that they are correct, complete, and satisfy safety requirements.
A.9.12 Non-operational hardware and software required for testing or maintenance should be clearly identified.
A.9.13 Existing code compiled with a new compiler or new release of a compiler should be regression tested.
A.9.14 Operators should not use beta test versions of language compilers or operating systems for safety-critical functions.
A.9.15 An operator should document and maintain test results in test reports.
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.