Appendix A 38 Timing errors. The state when software-timed events do not happen according to specification.
Data transmission errors.
Memory integrity loss.
Data rate errors. Greater than allowed safe input data rates.
Software exceptions. “Divide by zero” or “file not found.”
Message errors. Data transfer messages corrupted or not in the proper format.
Logic errors. Inadvertent instruction jumps.
A.3.5 Watchdog timers or similar devices should be used to ensure that the microprocessor or computer operates properly. For example, a watchdog timer should be used to verify events within an expected time budget or to ensure that cyclic processing loops complete within acceptable time constraints.
A.3.6 Watchdog timers or similar devices should be designed, so the software cannot enter an inner loop and reset the timer or similar device as part of that loop sequence.
Anomaly and Failure Response.
A.4.1 Software should provide fault containment mechanisms to prevent error propagation across replaceable unit interfaces.
A.4.2 All anomalies, software faults, hardware failures, and configuration inconsistencies should be reported to the appropriate system operator, safety official, or both, consoles in real time, prioritized as to severity, and logged to an audit file. The display should:
Distinguish between read and unread anomaly alerts;
Support reporting multiple anomalies;
Distinguish between anomaly alerts for which corrective action has been taken and those that still require attention; and Distinguish between routine and safety-critical alerts.
A.4.3 Upon detecting anomalies or failures, the software should:
Remain in or revert to a safe state;
Provide provisions for safing the hardware subsystems under the control of the software;
Reject erroneous input; and
Appendix A 39 Ensure the logging of all detected software safety-critical function system errors.
A.4.4 Upon detecting a failure during vehicle processing, the software should maintain the Flight Safety System (FSS) in its current state and meet the requirements in paragraph A.4.3 of this appendix. The software should maintain the FSS in the safe state. After the FSS is readied, the software should retain the FSS in the readied state. When the FSS receiver is on internal power, the software should maintain the FSS receiver on internal power. During flight, all detected FSS-related system errors should be transmitted to the safety official.
A.4.5 Details of each anomaly should be accessible with a single operator action.
A.4.6 Automatic recovery actions taken should be reported to the crew, operator, or controlling executive. There should be no necessary response from crew or ground operators to proceed with the recovery action.
A.4.7 Override commands should require multiple operator actions.
A.4.8 Software that executes hazardous commands should notify the initiating crew, ground operator, or controlling executive upon execution or provide the reason for failure to execute a hazardous command.
A.4.9 Hazardous processes and safing processes with a time-to-criticality such that timely human intervention may not be available should be automated. Such processes should not require human intervention to begin, accomplish interim tasks, or complete.
A.4.10 The software should notify the crew, ground operators, or controlling executive during or immediately after completing an automated hazardous or safing process.
A.4.11 After correction of erroneous entry, the software should provide positive confirmation of a valid data entry. The software should also provide an indication that the system is functioning properly.
Appendix A 40 Maintenance, Inhibits, and Interlocks.
A.5.1 Systems should include hardware and software interlocks and software controllable inhibits, as necessary, to mitigate hazards when performing maintenance or testing.
A.5.2 Interlocks should be designed to prevent an inadvertent override.
A.5.3 Interlocks that are required to be overridden should not be autonomously controlled by a computer system, unless dictated by a timing requirement.
A.5.4 Interlocks that are required to be overridden and are autonomously controlled by a computer system should be designed to prevent an inadvertent override.
A.5.5 The status of all interlocks should be displayed on the appropriate operator consoles.
A.5.6 An interlock should not be left in an overridden state once the system is restored to operational use.
A.5.7 A positive indication of interlock restoration should be provided and verified on the appropriate operator consoles before restoring a system to its operational state.
A.5.8 Software should make available status of all software controllable inhibits to the crew, ground operators, or controlling executive.
A.5.9 Software should accept and process crew, ground operator, or controlling executive commands to activate and deactivate software controllable inhibits.
A.5.10 Software should provide an independent and unique command to control each software controllable inhibit.
A.5.11 Software should incorporate the ability to identify and display the status of each software inhibit associated with hazardous commands.
A.5.12 Software should make available the current status on software inhibits associated with hazardous commands to the crew, ground operators, or controlling executive.
A.5.13 All software inhibits associated with a hazardous command should have a unique identifier.
A.5.14 If an automated sequence is already running when a software inhibit associated with a hazardous command is executed, the sequence should complete before the software inhibit is started.
Appendix A 41 A.5.15 Software should have the ability to resume control of an inhibited operation after deactivation of a software inhibit associated with a hazardous command.
A.5.16 The state of software inhibits should remain unchanged after the execution of an override.
Human-Computer Interface.
A.6.1 The system should be designed such that the operator may exit current processing to a known stable state with a single action and have the system revert to a safe state.
A.6.2 Computer systems should minimize the potential for inadvertent actuation of hazardous operations.
A.6.3 Only one operator at a time should control safety-critical computer system functions.
A.6.4 Operator-initiated hazardous functions should require two or more independent operator actions.
A.6.5 Software should provide confirmation to the operator of valid command entries, data entries, or both.
A.6.6 Software should provide feedback to the operator that indicates command receipt and status of the operation commanded.
A.6.7 Software should provide the operator with real-time status reports of operations and system elements.
A.6.8 Error messages should distinguish safety-critical states and errors from nonsafety-critical states and errors.
A.6.9 Error messages should be unambiguous.
A.6.10 Unique error messages should exist for each type of error.
A.6.11 The system should ensure that a single failure or error cannot prevent the operator from taking safing actions.
A.6.12 The system should provide feedback for any software safety-critical function actions not initiated.
A.6.13 Safety-critical commands that require several seconds or longer to process should provide a status indicator to the operator indicating that processing is occurring.
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.