U.S. Department of Transportation Federal Aviation Administration Advisory Circular Subject: Computing System Safety Date: August 16, 2021 Initiated By: AST-1 AC No: 450.141-1A Revision A This Advisory Circular (AC) provides guidance for an applicant to identify computing system safety items, develop safety requirements for each computing system safety item, and mitigate the risks presented by computing system safety items, in accordance with Title 14 of the Code of Federal Regulations (14 CFR) § 450.141. An applicant must identify all computing system safety items and implement safety requirements for each computing system safety item based on level of criticality, in accordance with § 450.141(a) and (b). An applicant must then implement a development process appropriate for each computing system safety item’s level of criticality, in accordance with § 450.141(c).
This AC describes acceptable means, but not the only means for demonstrating compliance with the regulatory requirements of § 450.141. It is intended to assist prospective applicants in obtaining commercial space authorizations and operating in compliance with commercial space regulations. The FAA will consider other means of compliance that an applicant may elect to present. The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. The document is intended only to provide clarity to the public regarding existing requirements under the law or agency policies.
If you have suggestions for improving this AC, you may use the Advisory Circular Feedback form at the end of this AC.
Contents Paragraph Page ii
1 Purpose2
2 Applicability2
3 Applicable Regulations and Related Guidance Documents3
4 Definition of Terms5
5 Means of Compliance8
6 Identification of Computing System Safety Items9
6.1 Identifying each Computing System Safety Item9
6.2 Assessment of Computing System Criticality11
7 Safety Requirements20
7.1 Identification of Safety Requirements20
7.2 Ensuring Safety Requirements are Complete and Correct21
7.2.1 Ensuring Safety Requirements are Complete21
7.2.2 Ensuring Safety Requirements are Correct21
7.3 Implementation and Verification of Safety Requirements21
7.3.1 Independent Validation and Verification21
7.3.2 Choosing Appropriate Validation and Verification Methods22
8 Development Process22
8.1 Development Process Rigor22
8.2 Development Process Requirements22
8.2.1 Responsibility Assignments22
8.2.2 Review and Approval Processes23
8.2.3 Training23
8.2.4 Traceability23
8.2.5 Configuration Management24
8.2.6 Validation and Verification24
8.2.7 Previously Developed Software and Computing Systems27
8.3 Development Process Considerations28
8.3.1 Analysis28
8.3.2 Development Standards29
8.3.3 Quality Assurance30
Contents (continued) Paragraph Page iii
8.3.4 Formal Inspections30
8.3.5 Anomaly Reports31
8.3.6 Maintenance and Repair of Computing System Hardware31
8.3.7 Maintenance of Computing System Software31
8.3.8 Building Maintainable Software31
9 Application Materials33
9.1 Computing System Safety Items33
9.2 Safety Requirements33
9.3 Development Process33
9.4 Providing Evidence of the Implementation of Each Safety Requirement34
9.5 Examples of Lessons Learned from Previous Space Vehicle Failures34
Appendix A. Generic Computing System Safety Requirements35
Appendix B. Software and Computing System Hazard Analyses48
Appendix C. Space Vehicles Failures and Aircraft Accidents60
Appendix D. Commercial, Military, and Experimental Aircraft Accidents69
Figures Number Page
Figure B-1 Fault Tree for Engine Shutdown Failure58
Figure B-2 Fault Tree for Software or Computing System Errors59
Tables Number Page
Table 1 – Examples of Error Conditions10
Table 2 – Public Safety Severity Categories14
Table 3 – MIL-STD-882E and GEIA-STD-0010A Software Control Categories16
Table 4 – NASA-GB-8719.13 Software Control Categories18
Table 5 – Testing Types26
Contents (continued) Paragraph Page iv
Table 6 – Verification Tests27
Table 7 – Software Implementation Analysis29
Table B-1 Example Classification of Software and Computing System Errors49
Table B-2 Example Software and Computing System Failure Modes and Effects Analysis
Worksheet53
Table B-3 Common Fault Tree Logic and Event Symbols57
Principal Changes Revision A updates AC 450.141-1, Computing System Safety, dated October 15, 2020. This AC change includes the following principal changes.
1. Moved paragraph 2.4 to paragraph 1.2 to maintain consistency across all AST ACs.
2. For paragraphs 4.13 and 4.14, revised definitions of terms “risk,” and “risk mitigation.”
3. For paragraph 6.1.2, revised second sentence to reference a functional hazard analysis.
4. For paragraph 6.2.3.1, added the phrase, “to make them consistent with § 450.141(a)(2) to the second sentence.
5. For paragraph 6.2.3.2, clarified reasonably foreseeable faults for a computing system are being those that an analyst can discover through methodical assessment of the system and the factors that interact with it.
6. For paragraph 6.2.4.1, added requirement regarding the level of criticality for computing system safety items.
7. Added paragraph 6.2.4.5.1 describing what a fault tolerance analysis should identify and what its criteria should include.
8. For paragraph 8.2.5, added a sentence that states configuration management processes start when an initial baseline configuration is identified.
9. For paragraph 8.2.6, updated discussion of validation and verification to encompass lessons learned.
10. Added footnote 3 on page 22 referencing the requirement of a system safety program be maintained during the lifecycle of a launch and reentry program.
11. For paragraph 8.3.6, clarified how maintenance affects computing system software during the lifecycle of that system.
12. Added paragraph 9.5 that clarifies the purpose of appendices D and E on lessons learned from historical space vehicle failures.
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.