2 1 PURPOSE.
1.1 This Advisory Circular (AC) provides guidance for identifying computing system safety items, developing safety requirements for each computing system safety item, and mitigating the risks presented by computing system safety items, in accordance with 14 CFR § 450.141. It is intended to provide guidance for an applicant in developing software and computing system safety analyses and processes to comply with § 450.141.
1.2 Level of Imperatives.
This AC presents one, but not the only, acceptable means of compliance with the associated regulatory requirements. The FAA will consider other means of compliance that an applicant may elect to present. Throughout this document, the word “must” characterizes statements that directly flow from regulatory text and therefore reflect regulatory mandates. The word “should” describes a requirement if electing to use this means of compliance; variation from these requirements is possible, but must be justified and approved as an alternative means of compliance. The word “may” describes variations or alternatives allowed within the accepted means of compliance set forth in this AC. In general, these alternative approaches can be used only under certain situations that do not compromise safety.
2 APPLICABILITY.
2.1 The guidance in this AC is for launch and reentry vehicle applicants and operators who are required to comply with 14 CFR part 450. The guidance in this AC is for those seeking a launch or reentry vehicle operator license, and a licensed operator seeking to renew or modify an existing vehicle operator license.
2.2 The material in this AC is advisory in nature and does not constitute a regulation. This guidance is not legally binding in its own right and the FAA will not rely upon this guidance as a separate basis for affirmative enforcement action or other administrative penalty. Conformity with this guidance document (as distinct from existing statutes and regulations) is voluntary only, and nonconformity will not affect rights and obligations under existing statutes and regulations. This AC describes acceptable means, but not the only means, for demonstrating compliance with the applicable regulations.
2.3 The material in this AC does not change or create any additional regulatory requirements, nor does it authorize changes to, or deviations from, existing regulatory requirements.
3 3 APPLICABLE REGULATIONS AND RELATED GUIDANCE DOCUMENTS.
3.1 Applicable Statute.
51 U.S.C. Subtitle V, Chapter 509.
3.2 Applicable FAA Commercial Space Transportation Regulations.
The following 14 CFR regulations must be accounted for when showing compliance with § 450.141. You can download the full text of these regulations from the U.S.
Government Printing Office e-CFR, or order a paper copy from the Government Printing Office, Superintendent of Documents, Attn: New Orders, PO Box 371954, Pittsburgh, PA, 15250-7954.
Section 401.7, Definitions.
Section 450.141, Computing System Safety.
3.3 Technical Reports Related to Computing System Safety.
1. Department of Defense, Standard Practice MIL-STD-882E, System Safety, May 11, 2012 (https://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=36027).
2. International Organization for Standardization (ISO), ISO/IEC/IEEE 29119-3:2013, Software and systems engineering – Software testing – Part 3: Test documentation, https://www.iso.org/standard/56737.html.
3. ISO/IEC TR 24772, Programming languages — Guidance to avoiding vulnerabilities in programming languages, ISO/IEC TR 24772, Programming languages — Guidance to avoiding vulnerabilities in programming languages.
4. Institute of Electrical and Electronic Engineers, IEEE 1012-2016/Corrigendum 1-2017, IEEE Draft Standard for System, Software and Hardware Verification and Validation – Corrigendum 1. https://standards-stg.ieee.org/standard/1012-2016- Cor1-2017.html.
5. Institute of Electrical and Electronic Engineers, IEEE 1228-1994, IEEE standard for Software Safety Plans, https://standards.ieee.org/standard/1228-1994.html.
6. Institute of Electrical and Electronic Engineers, IEEE/ISO/IEC 12207, International Standards Systems and software engineering – Software life cycle processes, https://standards.ieee.org/standard/12207-2017.html.
7. Joint Services Software Safety Committee, Software System Safety Handbook, Version 1, dated August 27, 2010, http://www.acqnotes.com/Attachments/Joint- SW-Systems-Safety-Engineering-Handbook.pdf.
8. National Aeronautics and Space Administration, NASA-STD-8739.8, Software Assurance and Software Safety Standard, https://standards.nasa.gov/standard/osma/nasa-std-87398.
9. National Aeronautics and Space Administration, NASA-STD-8739.9, Software Formal Inspections Standard, https://standards.nasa.gov/standard/osma/nasa-std- 87399.
10. National Aeronautics and Space Administration, NASA-GB-8719.13, NASA Software Safety Guidebook, dated March 31, 2004, https://standards.nasa.gov/standard/nasa/nasa-gb-871913
11. National Aeronautics and Space Administration, NASA-HDBK-2203, NASA Software Engineering and Assurance Handbook, dated April 4, 2020, https://standards.nasa.gov/standard/nasa/nasa-hdbk-2203.
12. Range Commanders Council, Range Safety Group, Flight Termination System Commonality Standard, RCC 319-19, White Sands, NM, 2019, https://www.wsmr.army.mil/RCCsite/Documents/319-19_FTS_Commonality/319- 19_FTS_Commonality.pdf.
13. Society of Automotive Engineers, GEIA-STD-0010A, Standard Best Practices for System Safety Program Development and Execution, dated October 18, 2018, https://www.sae.org/standards/content/geiastd0010a/?src=geiastd0010.
5 4 DEFINITION OF TERMS.
For this AC, the terms and definitions from § 401.7 and this list apply:
4.1 Commercial off-the-shelf (COTS) software.
Operating systems, libraries, applications, and other software purchased from a commercial vendor and not custom built for the applicant’s project.
4.2 Computing system safety item.
Any software or data that implements a capability that, by intended operation, unintended operation, or non-operation, can present a hazard to the public. A computing system safety item often contains several software functions assembled to meet a group of related requirements (e.g. an autonomous flight safety system (AFSS) or GPS).
4.3 Degree of control.
A computing system safety item’s importance in the causal chain for a hazard, in either causing or preventing the hazard.
4.4 Failure.
The inability of a computing system item to fulfill its operational requirements.
4.5 Failure Modes and Effects Analysis (FMEA).
An analysis of each potential failure in a system to determine the effects of each potential failure on the system and to classify each potential failure according to its severity and likelihood.
4.6 Fault.
An imperfection or deficiency in a computing system item that may contribute to a failure.
4.7 Fault Tree Analysis (FTA).
An analysis that identifies potential faults in the system and determines how those faults lead to a failure of the system to achieve its purpose. An FTA can include deductive system reliability analysis that provides qualitative and quantitative measures of the propensity for failure of a system, subsystem, or event.
4.8 Firmware.
Computer programs or data loaded into a class of memory that cannot be dynamically modified by the computer during processing. Firmware is treated as software.
4.9 Government off-the-shelf (GOTS) software.
Operating systems, libraries, applications, and other software obtained from a government entity and not custom built for the applicant’s project.
4.10 Level of criticality.
The risk posed by a computing system safety item, which is a combination of the severity of the hazards associated with the computing system safety item and the computing system safety item’s degree of control.
4.11 Memory.
Parts of an electronic digital computer that retain instructions and data for some interval of time. Memory is the electronic holding place for instructions and data that the microprocessor of a computer can access.
4.12 Risk.
Measure that takes into consideration, for hardware, the probability of occurrence and the consequence of a hazard to a population or installation. For computing systems, risk takes into consideration the computing system’s contributions to hazard causation or mitigation and the consequence of a hazard to a population or installation.
4.13 Risk mitigation.
Process of reducing either the likelihood or the severity of a risk for hardware. For software, risk mitigation is the process of reducing the severity, reducing the degree of control, or validating and verifying correct control.
4.14 Safety-critical computer system function.
Any computer system function whose proper recognition, control, performance, or tolerance, is essential to ensuring public safety and the safety of property.
4.15 Safety requirement.
A computing system requirement or software requirement defined for a computing system safety item that specifies an attribute or function that presents, mitigates, or is otherwise involved in a hazard to the public.
4.16 Software.
Computer programs, databases, and, possibly, associated documentation and data pertaining to the operation of a computer system. Operating system software that controls the basic functions of the computer system and application software that enables the computer to perform tasks are included, as are configuration files, databases, firmware, and supporting data structures.
4.17 Validation.
An evaluation to determine that each safety measure derived from a system safety process is correct, complete, consistent, unambiguous, verifiable, and technically feasible. Validation ensures that the right safety measure is implemented, and that the safety measure is well understood. 14 CFR 401.7.
4.18 Verification.
An evaluation to determine that safety measures derived from a system safety process are effective and have been properly implemented. Verification provides objective evidence that a safety measure reduces risk to acceptable levels. 14 CFR 401.7.
8 5 MEANS OF COMPLIANCE.
The guidance in chapters 6 through 9 of this AC details methods that an operator may use to demonstrate compliance with each of the requirements in § 450.141.
5.1 RCC 319-19 Tailoring.
An applicant may choose to demonstrate compliance with § 450.141 by tailoring Range Commanders Council, Range Safety Group, Flight Termination System Commonality Standard, RCC 319-19. The FAA will work with applicants to tailor RCC 319-19 to comply with § 450.141. A tailored RCC 319-19 used as a means of compliance for § 450.141 should be submitted to the FAA for acceptance prior to being included in a license application.1
1 RCC 319-19 is a flight termination system design standard. Applicants should carefully consider the requirements throughout RCC 319-19 prior to tailoring the requirements for systems other than flight termination systems.
9 6 IDENTIFICATION OF COMPUTING SYSTEM SAFETY ITEMS.
6.1 Identifying each Computing System Safety Item.
6.1.1 Section 450.141(a)(1) requires the applicant to identify any software or data that implements a capability that, by intended operation, unintended operation, or non-operation, can present a hazard to the public. In order to meet the requirement of § 450.141(a), an operator should define computing system safety items in a way that encompasses all of the software functions that work together in a given component. It is possible to isolate or partition a computing system safety item from non-safety functionality on a single hardware component such that the non-safety functions would not be part of the computing system safety item. RCC 319-19, Appendix A, discusses partitioning in greater detail.2 An applicant’s list of computing system safety items should at least include software that performs common safety-related functions, such as:
1. Software used to control or monitor safety-related systems.
2. Software that transmits safety data, including time-critical data and data about hazardous conditions.
3. Software used for fault detection in safety-related computer hardware or software.
4. Software that responds to the detection of a safety-related fault.
5. Software used in a flight safety system.
6. Processor-interrupt software associated with safety-related computer system functions.
7. Software that schedules the execution of safety related functions.
8. Software that computes safety-related data.
9. Software that accesses or manages safety-related data.
10. Software that displays safety data.
11. Software used for wind weighting.
6.1.2 Computing system safety items and their effects on public safety should be evident from the applicant’s functional hazard analysis, performed in accordance with § 450.107(b), as described in AC 450.107-1. If a system or subsystem hazard analysis identifies any software or data as potential hazard sources or hazard controls, then the applicant should perform a software hazard analysis, or extend the functional hazard analysis, to assess the hazard and the degree of control of any computing system safety item over the hazard, in accordance with § 450.141(a). Software hazard analyses identify potential software faults and their effects on the computing system and the system as a whole, as well as mitigation measures that can be used to reduce the risk.
2 If an operator isolates or partitions non-safety functionality from computing system safety items on a single hardware component, then the isolation or partition would become a safety requirement that must be verified by testing appropriate for the highest criticality function performed by the hardware component, in accordance with § 450.141(b).
10 Typical software hazard analyses include Software Failure Modes Effects Analysis (SFMEA) and Software Fault Tree Analysis (SFTA). Appendix B of this AC and the Joint Services Software Safety Committee (JSSSC) Software System Safety Handbook provides examples of SFMEA and SFTA. The analytical method and level of detail in the analysis should correspond to the complexity of the software and computing system, intricacy of the operations, and scope of the program. An applicant’s software hazard analyses should consider a range of potential error conditions, as described in Table 1 of this AC. Appendix B of this AC provides an example of a classification scheme for software and computing system errors that an applicant can use to develop its hazard analysis.
Table 1.1 – Examples of Calculation or Computation Errors Error Condition Examples Incorrect algorithms The software may perform calculations incorrectly because of mistaken requirements or inaccurate coding of requirements.
Calculation overflow or underflow The algorithm may result in a divide by zero condition.
Table 2.2 – Examples of Data Error Conditions Error Condition Examples Improper data The software may receive out of range or incorrect input data;
no data because of transducer drop out; wrong data type or size, or untimely data; produce incorrect or no output data, or both.
Input data stuck at some value A sensor or actuator could always read zero, one, or some other value.
Large data rates The software may be unable to handle large amounts of data or many user inputs simultaneously.
11 Table 3.3 – Examples of Logic Errors Error Condition Examples Improper or unexpected commands The software may receive bad data but continues to run a process, thereby doing the right thing under the wrong circumstances.
Failure to issue a command The software may not invoke a routine.
Command out of sequence A module may be executed in the wrong sequence, or a system operator may interrupt a process leading to an out of sequence command.
Race condition/incorrect timing Software processes may have timing dependencies, within or between processes, which cause unintended data alterations at random times. System operators can interrupt processes causing a problem in timing sequences, or processes may run at the wrong times.
Table 4.4 – Examples of Interface Errors Error Condition Examples Incorrect, unclear, or missing messaging A message may be incorrect, unclear, or missing, leading to the system operator making a wrong decision.
Poor interface design and layout An unclear graphical user interface can lead to an operator making a poor decision.
Inability to start or exit processing safely A system operator may be unable to start or stop a test of a flight safety system once the automated routines have started.
Multiple events occurring simultaneously A system operator may provide input in addition to expected automated inputs during software processing.
12 Table 5.5 – Examples of Software Development Environment Errors Error Condition Examples Improper use of tools Turning on the compiler option to optimize or debug the code in production software may lead to a software fault.
Changes in the operating system or commercial software module Upgrades to an operating system may lead to a software fault.
Table 6.6 – Examples of Hardware-Related Errors Error Condition Examples Unexpected shutdown of the computing system Loss of power to the CPU or a power transient may damage circuits.
Memory overwriting Improper memory management may cause overwriting of memory space and unexpected results.
6.2 Assessment of Computing System Criticality.
6.2.1 Section 450.141(a)(2) requires an applicant to identify the level of criticality of each computing system safety item, commensurate with its degree of control over hazards to the public and the severity of those hazards. A level of criticality is specified by the combination of the severity of hazards associated with a computing system safety item and the computing system safety item’s degree of control over those hazards.
6.2.2 To satisfy § 450.141(a)(2), an applicant should first define the severities of hazard consequences of interest for its system, then assign degrees of control to computing system safety items using a framework that will enable the FAA to validate the appropriate severity and control categorization. An applicant could assess degrees of control using any of the following methods:
1. Assumption of high criticality: An applicant could simplify the assessment of the criticality of each computing system safety item by assuming that all computing systems have the highest criticality level.
2. RCC 319-19, Section A.3.1.1, defines software categories for flight safety systems.
3. MIL-STD-882E, Section 4.4, or GEIA-STD-0010A, Section A.6 defines software control categories and a software criticality index.
4. NASA-GB-8719.13, Section 3.1.2 defines software control categories and a software risk index.
5. Fault tolerance: an applicant could also use the fault tolerance method described in this section to assess system level criticality.
6.2.3 Consequence Definitions.
To assess the criticality of computing system safety items, an applicant should first define the hazard consequences of interest for its system. Applicants should define hazard consequences such that computing system safety items fit in one or more consequence categories. An applicant should consider the FAA’s definitions of the words “mishap,” “anomaly,” “casualty,” “public,” and “safety critical” in § 401.7 when composing its consequence definitions.
6.2.3.1 Option 1: Public Safety Consequence Categories.
Guidance document MIL-STD-882E and GEIA-STD-0010A define hazard consequence categories (see references [1] and [13] of paragraph 3.3 of this AC). Since the severity categories in these standards do not explicitly identify public safety consequences, an applicant for a Part 450 license must tailor the MIL-STD-882E or GEIA-STD-0010A severity tables for public safety to make them consistent with § 450.141(a)(2). This may result in something similar to Table 2, Public Safety Severity Categories, with revisions in bold underline.