26 Table 10 – Testing Types Test Comments Unit Demonstrates correct functioning of critical software elements.
Interface Shows that critical computer software units execute together as specified.
System Demonstrates the performance of the software within the overall system throughout the planned mission duration.
Stress Confirms the software will not cause hazards under abnormal circumstances, such as unexpected input values, overload conditions, or off-nominal mission timelines.
Regression Demonstrates changes made to the software did not introduce conditions for new hazards.
8.2.6.3 Test Cases.
The applicant should also define specific test cases with pass and fail criteria. Test cases describe the inputs, predicted results, test conditions, and procedures for conducting the test. The applicant should design test cases to ensure that all safety requirements are covered. These test cases should include scenarios that demonstrate the ability of the software to respond to both nominal and off-nominal inputs and conditions.
Off-nominal and failure test scenarios often come from the hazard analysis.
8.2.6.4 Test Log.
The applicant should record the results of the tests; this is often done in a test log. Anomalies discovered during testing should also be recorded.
ISO/IEC/IEEE 29119-3:2013 provides additional information on test documentation. The recorded test results need to include the version of the software that was tested. See reference [2] of paragraph 3.3 of this AC.
8.2.6.5 Verification Tests.
Testing traditionally has been relied on to verify that computing system requirements have been met and have been implemented correctly. There are several types of tests available, shown in Table 6, and verification testing is normally a combination of many or all types. The applicant should use a combination of verification approaches that are appropriate for its software system (analysis, inspection, and test), including testing to the extent practicable. The applicant should also use proven methods to verify the software requirements, which include, but are not limited, to the verification tests listed in Table 6 of this AC.
27 Table 11 – Verification Tests Test Comments Equivalence partitioning Identifying valid and invalid classes of input conditions. If, for example, an input field calls for values between 1 and 10, inclusive, then a valid equivalence class would be all values between and including 1 and 10. Invalid equivalent classes would be values less than 1 and values greater than 10.
Boundary value Testing at the extremes of an input condition, values close to those extremes, and crossing those boundaries. If, for example, an input field calls for values between 0 and 100 with a precision of 0.01, then test inputs could include 0, 100, -0.01,
100.01, 0.01, and 99.99. Test inputs that exceed the implicit boundaries of allocated memory, such as 129 or -128 for an 8-bit signed integer, should also be included.
Error guessing Using empty or null lists and strings, negative numbers, null characters in a string, and incorrect entry types.
Statement coverage Ensuring that each instruction is executed at least once and instruction execution produces the expected response.
Decision coverage Ensuring that each decision takes on all possible outcomes at least once. For example, assuring that all “if” and “while” statements are evaluated to both true and false.
Function coverage Determining whether each function or procedure was invoked.
Call coverage Verifying that each function call has been completed at least once and produced the expected results.
8.2.7 Previously Developed Software and Computing Systems.
As required by § 450.141(c)(7), an applicant must validate and verify the safety requirements for reused computing system safety items. In addition, an applicant must validate and verify the safety requirements for third-party products, as required by § 450.141(c)(8). Using previously developed computing system safety items can reduce development time, because those components have already undergone design and testing. However, analysis of accidents where software was a contributing factor shows the risks in this approach. Previously-developed computing system safety items include commercial off-the-shelf (COTS) software, government off-the-shelf (GOTS) software, and “reused” software. Although another vendor may have developed the software or product, reducing the risks of using third-party products remains the responsibility of the applicant. These risk reduction efforts should include evaluating the differences
28 between the computing system safety item’s role in the new system and its use in the previous system, including assessment of any identified issues found during use in the previous system and implementation of all preconditions for its use in the new system.
For third-party computing system safety items, risk reduction efforts should include verification of compliance with the developer’s specified uses for third-party products and verification of safety requirements for its use in the system.
8.3 Development Process Considerations.
The rest of this chapter outlines considerations that may guide applicants in formulating development processes that satisfy § 450.141(c) and, more generally, the performancebased requirements of § 450.141.
8.3.1 Analysis.
Analyses to verify that the software requirements are implemented correctly could include the components described in Table 7 of this AC. Additional information about software analysis methods is available in IEEE 1228-1994 and the Joint Services Software Safety Committee (JSSSC) Software System Safety Handbook. See references [5] and [7] of paragraph 3.3 of this AC.
29 Table 12 – Software Implementation Analysis Analysis Comments Logic Evaluates the sequence of operations represented by the coded program and detects programming errors that might create hazards.
Data Evaluates the data structure and usage in the code to ensure each is defined and used properly by the program. Analysis of the data items used by the program is usually performed in conjunction with logic analysis.
Interface Ensures compatibility of program modules with each other and with external hardware and software.
Constraint Ensures that the program operates within the constraints imposed upon it by requirements, design, and target computer. Constraint analysis is designed to identify these limitations, ensure that the program operates within them, and make sure that all interfaces have been considered for out-of-sequence and erroneous inputs.
Programming style Ensures that all portions of the program follow approved programming guidelines.
Non-critical code Examines portions of the code that are not considered safety-critical code to ensure that they do not cause hazards. As a general rule, safety-critical code could be isolated from non-safety-critical code. The intent of this analysis is to prove that this isolation is complete and that interfaces between safetycritical code and non-safety-critical code do not create hazards.
Timing and sizing Evaluates safety implications of safety-critical requirements that relate to execution time, clock time, and memory allocation.
8.3.2 Development Standards.
The applicant may identify development standards that define the rules and constraints for the development process in accordance with § 450.141(c). The use of development standards can enable uniformly designed and implemented computing system safety items. They can prevent the use of methods that are incompatible with safety requirements. Referencing a standard may produce a compelling rationale for the acceptance of a development process. RCC 319-19 defines a development standard that is sufficient for a flight safety system. An applicant can meet § 450.141(c) by demonstrating compliance with RCC 319-19. See reference [12] of paragraph 3.3 of this AC. Regardless of the standard or its use in the proposed operation, the application could establish an understanding of the parts of each standard that has been adopted by
30 the applicant, how each part of each standard is used in the proposed development and operation, and how each part of each standard supports public safety. Development standards include requirements, design, coding, and safety standards, as follows:
Requirements standards may include methods for developing requirements and a description of how the requirements flow down to coding.
Design standards may include restrictions on the use of scheduling and interrupts, specification of usable code libraries, or rules for conditional branches to reduce complexity.
Coding standards may include specifications for the programming language;
naming conventions for modules, variables, and constants; and constraints on the use of tools.
Safety standards may include approaches for analyzing risk and classifying hazards, such as MIL-STD-882 or GEIA-STD-0010A. See references [1] and [13] of paragraph 3.3 of this AC.
8.3.3 Quality Assurance.
Quality assurance may support the achievement of the performance objectives in § 450.141. Quality assurance verifies that the objectives and requirements of the software system safety program are satisfied and confirms that deficiencies are detected, evaluated, tracked, and resolved. An acceptable quality assurance function should include audits and inspections of elements and processes, such as plans, standards, and problem tracking and configuration management systems. In addition, the quality assurance function could evaluate the validity of system safety data. NASA Software Assurance and Software Safety Standard (NASA-STD-8739.8), and NASA Software Engineering and Assurance Handbook (NASA-HDBK-2203) provide examples of acceptable software quality assurance methods. See references [8] and [11] of paragraph
3.3 of this AC.
8.3.4 Formal Inspections.
Formal inspections are well thought out technical reviews that provide a structured way to find and eliminate defects in documentation products, ranging from a requirements document to the actual source code. These inspections differ from informal reviews or walkthroughs since there are specified steps to be taken and roles assigned to individual reviewers. As required by § 450.141(c)(2), a process must be defined for internal review and approval such that no person approves their own work. Further information regarding formal inspections can be found in NASA-STD-8739.9, Software Formal Inspections Standard. See reference [9] of paragraph 3.3 of this AC.
8.3.5 Anomaly Reports.
To help prevent recurrence of computing system safety-related anomalies, the applicant could develop a standardized process to document anomalies, analyze the root cause, and determine corrective actions. Software anomaly reports (also known as problem reports) are a means to identify and record:
Computing system anomalous behavior and its resolution, including failure to respond properly to nominal and off-nominal conditions.
Development process non-compliance with software, requirements, plans, and standards, including improperly implemented safety measures.
Deficiencies in documentation and safety data, including invalid requirements.
8.3.6 Maintenance and Repair of Computing System Hardware.
While software does not wear out, maintenance engineering ensures that systems and subsystems will remain at the design safety level by minimizing computing system hardware wear-out failures through replacement of failed items and surveillance for possible degradation due to environments. Maintenance engineering personnel also participate in analyzing the safety implications of proposed maintenance procedures on the ground and in flight. Therefore, the applicant could perform activities to aid maintenance and repair of computing system hardware.
8.3.7 Maintenance of Computing System Software.
Software maintenance differs from hardware maintenance because software does not wear out or degrade in the same way that hardware does. However, software maintenance corrects defects; adds or removes features and capabilities; compensates for or adapts to hardware changes, wear-out, or failure; and accommodates changes in other computing system safety items or system components. Changes to both the hardware and software after deployment can produce computing system anomalies. An applicant could identify a process for verifying the integrity of the safety-critical software and computing systems after deployment. Examples of such verification methods include the use of checksums and parity bit checks to ensure proper data transfer, built-in or external measures for evaluating the software and its data, inspections to detect unauthorized modification of the software or its data, and regression testing.
8.3.8 Building Maintainable Software.
Because software changes can be expected over the lifecycle of the product, an applicant could build maintainable software to facilitate those changes and reduce the likelihood of introducing new hazards. NASA-GB-8719.13 provides additional information on software maintainability. See reference [10] of paragraph 3.3 of this AC.
Considerations for building maintainable software include:
Planning early for expected changes.
Using strong configuration management practices.
32 Using modular design, where appropriate, to minimize the overall impact of changes.
Implementing naming conventions for variables to improve code readability.
Using comment and style coding standards to improve code readability.
Implementing documentation standards to make important information easy to find.
Using a standardized set of development tools to reduce the chance of introducing errors in code changes.
Assuring that design and verification documentation, such as regression tests and test cases, are updated and maintained.
33 9 APPLICATION MATERIALS.
This chapter provides guidance on satisfying the application requirements set forth in § 450.141(d). In accordance with § 450.141(d), an application must include:
Descriptions of all computing system safety items involved in the proposed operations;
All safety requirements for each computing system safety item;
Documentation of the software development process that meets § 450.141(c);
Evidence of the execution of appropriate development processes for each computing system safety item; and Evidence of the implementation of each safety requirement.
9.1 Computing System Safety Items.
An applicant must identify and describe all computing system safety items involved in its proposed operation, in accordance with § 450.141(d)(1). These descriptions should include the severity of hazards associated with each computing system safety item and the computing system safety item’s level of criticality regarding each hazard. The descriptions of computing system safety items and their criticality allow the applicant to know, and the FAA to verify, how each computing system safety item influences public safety when combined with the other requirements in § 450.141.
9.2 Safety Requirements.
An applicant must identify the safety requirements for each computing system safety item, in accordance with § 450.141(d)(2). Although § 450.141(d)(2) only requires applicants to identify safety requirements, an applicant may, and is encouraged to, submit all computing system requirements for its computing system safety items in order to effectively convey the software’s intended functionality to the FAA. State diagrams, user manuals, flow charts, and other documents are helpful to communicate computing system requirements.
9.3 Development Process.
Section § 450.141(d)(3) requires applicants to submit documentation of the development process that meets § 450.141(c), including the minimum attributes required by the regulation. Similarly, § 450.141(d)(4) requires an applicant to provide evidence of the execution of the appropriate development process for each computing system safety item. An applicant must demonstrate its development process for each computing system safety item in accordance with § 450.141(d)(3), and each development process must meet § 450.141(c). If a development process contains more than one distinct set of development process requirements, such as a set of development requirements for applicant-developed computing system safety items and another set for third-party products, then the applicant should specify which set was executed for each computing system safety item. The documentation required of an applicant to meet these requirements will vary among applications, depending on the complexity of the computing system safety item, but will generally include some combination of audit
34 results, milestone results, and outputs of automated code checking tools. Substantive guidance on demonstrating compliance with § 450.141(c) is provided in paragraph 8.2 of this AC. A software hazard analysis is often needed to ensure that test cases address all necessary nominal and off-nominal conditions, and it expands in scope throughout the development process. Although the test cases trace to requirements, the hazard analysis validates the content of the tests.
9.4 Providing Evidence of the Implementation of Each Safety Requirement.
Section 450.141(d)(5) requires the submission of evidence of the implementation of each safety requirement. An applicant should submit the combination of test descriptions, test plans, test outputs, and analyses that verifies that each computing system safety item meets each applicable safety requirement. Applicants that plan repeated missions with identical computing system safety items may define a standard set of test reports.
9.5 Examples of Lessons Learned from Previous Space Vehicle Failures.
Appendices C and D of this AC provide examples of lessons learned from previous system failures in which software and its associated computing system hardware have played a significant role. The information provided in these appendices is intended to provide an understanding of the types of failures that have been observed in software and computing systems and provide lessons learned for the design of future systems.
Appendix A
35 APPENDIX A. GENERIC COMPUTING SYSTEM SAFETY REQUIREMENTS.
This appendix provides generic computing system safety requirements that an applicant may use in the design and development of software and computing systems. These generic design requirements represent best practices used in the aerospace community, and are offered here as examples of safety requirements for any application under § 450.141. Additional information and sample requirements can be found in the following references:
FAA System Safety Handbook (2002) Joint Services Software Safety Committee Software System Safety Handbook (1999) NASA Software Safety Guidebook (2004) Range Safety User Requirements Manual: Air Force Space Command Range Safety Policies and Procedures (2004) Sample General Computing System Requirements.4 A.1.1 Computer systems should be validated for operation in the intended use and environment. Such validation should include testing under operational conditions and environments.
A.1.2 Under maximum system loads, CPU throughput should not exceed 80 percent of its design value.
A.1.3 Computer system architecture should be single fault tolerant. No single software fault or output should initiate a hazardous operation, cause a critical accident, or cause a catastrophic accident.
A.1.4 Safety-critical computer system flight architecture that will be exposed to cosmic radiation should protect against CPU single event upset and other single event effects. A single event upset occurs when an energetic particle travels through a transistor substrate and causes electrical signals within a component.
A.1.5 Sensitive components of computer systems should be protected against the harmful effects of electromagnetic radiation, electrostatic discharges, or both.
A.1.6 The computer system should verify periodically that safety-critical computer hardware and software safety-critical functions, including safety data transmission, operate correctly.
4 The requirements in this appendix are computing system design requirements as opposed to regulatory requirements.
Appendix A 36 A.1.7 The computer system should verify periodically the validity of real-time software safety data, where applicable.
A.1.8 Software should process the necessary commands within the time-to-criticality of a hazardous event.
A.1.9 Memory allocation should occur only at initialization.
A.1.10 If the system begins to use areas of memory that are not part of the valid program code, the system should revert to a safe state.
A.1.11 Memory partitions, such as RAM, should be cleared before loading software.
A.1.12 Prerequisite conditions for the safe execution of an identified hazardous command should exist before starting the command. Examples of these conditions include correct mode, correct configuration, component availability, proper sequence, and parameters in range. If prerequisite conditions have not been met, the software should reject the command and alert the crew, ground operators, or controlling executive.
A.1.13 Provisions to protect the accessibility of memory region instructions, data dedicated to critical software functions, or both, should exist.
A.1.14 Software should provide proper sequencing, including timing, of safety-critical commands.
A.1.15 Where practical, software safety-critical functions should be performed on a standalone computer. If that is not practical, software safety-critical functions should be isolated to the maximum extent practical from non-critical functions.
A.1.16 Documentation describing the software and computing system should be developed and maintained to facilitate maintenance of the software.
A.1.17 The software should be annotated, designed, and documented for ease of analysis, maintenance, and testing of future changes to the software.
A.1.18 Interrupt priorities and responses should be specifically defined, documented, analyzed, and implemented for safety impact.
A.1.19 Critical software design and code should be structured to enhance comprehension of decision logic.
A.1.20 Software code should be modular in an effort to reduce logic errors and improve logic error detection and correction functions.
A.1.21 The software should be initiated and terminated in a safe state.
Appendix A 37 A.1.22 Critical hardware controlled by software should be initialized to a known safe state.
A.1.23 NASA Software Engineering Requirements (NPR 7150.2C) requirement SWE-134 provides an alternative set of requirements that is helpful in determining a full set of software requirements for safety critical applications.
A.2 Computing System Power.
A.2.1 Computer systems should be powered up, restarted, and shutdown in a safe state.
A.2.2 A computer system should not enter a hazardous state as a result of an intermittent power transient or fluctuation.
A.2.3 If a single failure of primary power to a computer system or computer system component occurs, then that system or some cooperating system should take action automatically to transition to a stable state.
A.2.4 Software used to power up safety-critical systems should power up the required systems in a safe state.
Anomaly and Failure Detection.
A.3.1 Single event system failures should be protected against by employing mitigating approaches, as appropriate, such as redundancy, error-correcting memory, and voting between parallel CPUs.
A.3.2 Before initiating hazardous operations, computer systems should perform checks to ensure that they are in a safe state and functioning properly. Examples include checking safety-critical circuits, components, inhibits, interlocks, exception limits, safing logic, memory integrity, and program loads.
A.3.3 Failure of software safety-critical functions should be detected, isolated, and recovered from in a manner that prevents catastrophic and critical hazardous events from occurring.
A.3.4 Software should provide error handling to support software safety-critical functions. The following hazardous conditions and failures, including those from multiple sources, should be detected:
Input errors. Data or sequences of data passed to software modules, either by human input, other software modules, or environmental sensors, that are outside a specified range for safe operation.
Output errors. Data output from software modules that are outside a specified range for safe operation.